MySQL查询被KILL掉通常因超时机制（如wait_timeout、max_execution_time）或OOM Killer触发；dmesg可确认是否OOM；max_execution_time仅对SELECT生效且不释放锁，应谨慎使用。MySQL查询被KILL掉是因为连接超时还是OOM？高负载下查询中断，八成不是"卡死"，而是被MySQL自己或系统主动终止。得先分清是wait_timeout、max_execution_time这类超时机制干的，还是Linux OOM Killer把mysqld进程杀掉了。查dmesg -T | grep -i "killed process"，如果看到mysqld出现在输出里，那就是内存真不够用了，调参数没用，得先保命。max_execution_time设太高反而更危险这个参数看着是"防长查询"，但设成0（禁用）或几万毫秒，容易让慢查询霸占线程、拖垮整个连接池。尤其在OLTP场景下，一个SELECT ... JOIN卡住30秒，可能连带阻塞几十个新请求。真正该做的是：对已知慢的业务SQL加MAX_EXECUTION_TIME提示，而不是全局放开：SELECT /*+ MAX_EXECUTION_TIME(5000) */ id, name FROM orders WHERE ...max_execution_time只对SELECT生效，UPDATE/DELETE无效它不释放锁，超时后事务仍处于活跃状态，可能造成隐式锁等待和innodb_lock_wait_timeout是两套机制，别混淆innodb_buffer_pool_size不能无脑拉到物理内存80%很多人看到"建议设为总内存70%~80%"就照搬，结果在48G机器上配了38G，却忘了OS还要缓存文件、网络栈、其他进程。MySQL真能用满？不一定。看SHOW ENGINE INNODB STATUS里的Buffer pool hit rate，长期低于99.5%才说明真缺；再看Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值，大于1000才算健康。否则就是堆了内存也白搭，还挤占了page cache，让磁盘IO更抖。 Cleanup.pictures 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西