SQL执行卡死常因AJAX超时误判，实际是前端默认超时（如axios 10秒）早于后端SQL执行完成；需正确配置请求级timeout、数据库queryTimeout及异步任务机制。
SQL执行卡死，本质是AJAX超时在“背锅”
前端发请求后页面假死、控制台报 net::err_connection_timed_out 或 504 gateway timeout，大概率不是sql慢，而是ajax默认超时（通常30秒）先扛不住了。后端sql可能还在跑，但前端早已断连，用户刷新重试反而加重数据库压力。
- 浏览器原生
fetch默认无超时，但多数人用的axios默认设了timeout: 10000（10秒），远低于长SQL实际耗时 - Node.js 后端用
express+mysql2时，连接池的acquireTimeout和查询本身的queryTimeout是两回事，别混为一谈 - PHP 的
max_execution_time、Python Flask 的timeout配置，只管后端脚本生命周期，不自动传导给前端 AJAX
axios 超时要改对地方：request 还是 response？
很多人改了 axios.defaults.timeout 发现没用——因为这个只影响未显式配置 timeout 的实例，而项目里往往用了自定义 instance。真正该动的是发起请求时的 config 对象。
- 错：改全局默认值，但业务代码里写了
axios.post(url, data)没传 config → 不生效 - 对：统一在封装的请求函数里加
timeout: 300000（5分钟），例如：api.post('/report/run', data, { timeout: 300000 }) - 注意：超时值设太高有风险，移动端弱网下用户会长时间干等，建议配合
onUploadProgress显示进度条或轮询状态接口
后端必须配 queryTimeout，否则前端再调也没用
MySQL 连接被占着不释放，或者查询被服务端主动 kill，前端即使延长超时也白搭。关键在数据库驱动层的 query 级超时控制。
- Node.js +
mysql2：创建连接时设queryTimeout: 300000，不是connectTimeout（那是连不上数据库时的等待） - Java +
HikariCP：配connection-timeout是建连超时，真正要加的是 SQL 执行级的setQueryTimeout(300)（单位秒） - Python +
pymysql：直接在cursor.execute(sql, args, timeout=300)传 timeout 参数；sqlalchemy则需在create_engine里加connect_args={'read_timeout': 300, 'write_timeout': 300}
别只盯着超时，长SQL本身得可中断、可感知
单纯拉长超时只是掩耳盗铃。用户点了“导出全年订单”，结果卡住5分钟没反馈，大概率会反复点击，触发多条重复查询。
- 把同步执行改成异步任务：前端提交后立刻返回
{ task_id: "abc123" }，再用GET /task/status?task_id=abc123轮询 - SQL 层面加
LIMIT和分页逻辑，避免SELECT * FROM huge_table这种无防护操作 - PostgreSQL 可用
SET statement_timeout = '300s'在会话级兜底；MySQL 5.7+ 支持MAX_EXECUTION_TIMEhint，例如SELECT /*+ MAX_EXECUTION_TIME(300000) */ ...
最麻烦的其实是事务隔离级别和锁等待——超时设置再细，遇上行锁死等，照样卡住。这类问题得看 SHOW ENGINE INNODB STATUS，不是调个 timeout 就能绕开的。
