SQL数据库查询执行采用协作式模型，非抢占式；长查询不会自动中断，需人工干预或超时配置。
SQL数据库本身没有内置的“查询抢占机制”，长查询不会被自动中断，除非人为干预或配置了超时策略。
查询执行是独占还是抢占？
大多数关系型数据库（如MySQL、PostgreSQL、SQL Server）采用**协作式执行模型**，不是操作系统级的抢占式调度。一个查询一旦开始执行，会持续占用CPU、I/O和内存资源，直到完成、出错或被外部终止。它不会因为另一个更高优先级的查询到来而主动让出执行权。
这意味着：
- 长事务或复杂JOIN/ORDER BY/GROUP BY可能长时间阻塞其他查询（尤其涉及锁表或行锁等待时）
- 没有默认的“查询优先级”或“时间片轮转”机制
- 所谓“抢占”，实际依赖DBA或应用层主动识别并终止异常查询
常见中断长查询的方式
不同数据库提供对应的会话管理命令，用于手动或自动中止运行中的查询：
- MySQL：通过 SHOW PROCESSLIST 查看活跃连接，用 KILL [connection_id] 终止指定会话；也可配置 max_execution_time（5.7+）对SELECT语句设毫秒级超时
- PostgreSQL：查询 pg_stat_activity 获取pid，执行 SELECT pg_cancel_backend(pid) 中断查询（保留连接），或 pg_terminate_backend(pid) 彻底断开
- SQL Server：用 sp_who2 或 sys.dm_exec_sessions 找到session_id，再执行 KILL [session_id]
- 通用做法：在应用层设置查询超时（如JDBC的setQueryTimeout、Python psycopg2的command_timeout），由驱动在超时后向数据库发送中断信号
预防胜于中断：降低长查询发生概率
比起事后杀进程，更有效的是从设计和运维层面减少长查询出现：
- 为高频查询字段添加合适索引，避免全表扫描
- 限制返回结果集大小（加 LIMIT / TOP），尤其在调试或前端分页场景
- 拆分超大事务，避免单次更新/删除百万级数据
- 定期分析慢查询日志（如MySQL slow_log、PostgreSQL log_min_duration_statement），针对性优化
- 在业务低峰期执行统计类、报表类长耗时SQL，并加注释说明用途与预期耗时
注意：中断不等于回滚完成
执行KILL或cancel操作后，数据库需清理资源、释放锁、回滚未提交的变更。若长查询已修改大量数据，回滚本身也可能耗时很久，期间仍可能阻塞其他操作。因此，中断只是“停止继续执行”，不代表立即释放所有资源。
