先判断超时类型，再逐层排查。检查timeout参数、活跃会话状态、锁等待情况，启用慢查询日志分析执行计划与索引使用，结合系统资源和并发监控定位问题根源。
MySQL执行超时问题通常表现为查询长时间未响应或客户端报“Lock wait timeout exceeded”“Query execution was interrupted”等错误。排查这类问题需要从连接、语句执行、锁竞争、系统资源等多个维度分析。以下是实用的定位思路和操作方法。
1. 确认超时类型与参数设置
MySQL中有多种超时参数，需先明确是哪种超时：
- connect_timeout：连接建立阶段超时，默认5-10秒
- wait_timeout / interactive_timeout：空闲连接自动断开时间（默认8小时）
- net_read_timeout / net_write_timeout：网络读写超时（默认30秒）
- innodb_lock_wait_timeout：行锁等待超时（默认50秒）
- lock_wait_timeout：元数据锁等待超时（默认31536000秒）
- max_execution_time（仅MySQL 5.7+）：SELECT语句最大执行时间（单位毫秒）
查看当前会话或全局设置：
SHOW VARIABLES LIKE '%timeout%';重点关注innodb_lock_wait_timeout和max_execution_time，这两个最常导致“执行超时”现象。
2. 检查正在执行的慢查询
通过information_schema.PROCESSLIST或SHOW PROCESSLIST查看当前活跃会话：
关注字段：
- TIME：执行已耗时，过长说明卡住
- STATE：如“Sending data”“Copying to tmp table”“Locked”等状态可提示瓶颈
- INFO：实际执行的SQL语句（可能为NULL）
若看到大量线程处于同一STATE，可能是资源争用或索引缺失。
3. 分析锁等待情况
若报错“Lock wait timeout exceeded”，应检查InnoDB锁信息：
SELECT * FROM information_schema.INNODB_TRX\GSELECT * FROM information_schema.INNODB_LOCKS\GSELECT * FROM information_schema.INNODB_LOCK_WAITS\G重点看：
结合PROCESSLIST找到对应SQL，通常是未提交事务或长事务阻塞了其他操作。
4. 启用慢查询日志定位性能差的SQL
确保慢查询日志开启，并设置合理阈值：
SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1;SET GLOBAL log_output = 'TABLE';执行一段时间后查询：
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;分析输出中的query_time、lock_time、rows_examined等字段，找出扫描行数多、未走索引的SQL。
5. 检查执行计划与索引使用
对可疑SQL使用EXPLAIN分析执行路径：
EXPLAIN FORMAT=JSON SELECT ...关注：
- type是否为ALL（全表扫描）
- possible_keys与key是否为空
- rows数值是否过大
- Extra是否有Using filesort、Using temporary等高成本操作
根据结果添加索引或改写SQL。
6. 监控系统资源与并发压力
MySQL性能也受服务器资源影响：
- 使用top/vmstat/iostat查看CPU、内存、IO是否瓶颈
- 检查MySQL的Threads_connected、Threads_running指标是否异常高
- 观察Innodb_row_lock_waits、Innodb_row_lock_time等状态值
高并发下连接池打满也可能导致“假超时”。
基本上就这些。关键是先判断是锁等待、执行慢还是网络/连接问题，再逐层深入。日常建议开启慢日志，定期巡检长事务，避免大事务和全表扫描。
