如何为MySQL后端访问设置优先级？（含InnoDB/PHP业务场景）

嘿，这个场景太常见了——核心业务的并发锁事务遇上后台监控的统计查询，很容易出现资源争抢的问题，尤其是你用了SELECT ... FOR UPDATE这种加排他锁的语句，得好好把优先级捋清楚。结合你用的InnoDB引擎和PHP栈，我给你几个能直接落地的方案：

1. 会话级优先级直接设置 #

MySQL支持针对单个会话设置查询优先级，你可以给业务事务的连接设高优先级，监控查询的连接设低优先级：

• 业务连接初始化时：执行SET SESSION priority = HIGH_PRIORITY;，这样后续的SELECT ... FOR UPDATE和UPDATE都会以高优先级执行。
• 监控连接初始化时：执行SET SESSION priority = LOW_PRIORITY;，让统计查询主动“让路”给核心业务。

在PHP里实现也很简单，比如用PDO的话，监控连接初始化后直接加一句：

$monitorPdo->exec("SET SESSION priority = LOW_PRIORITY;");

mysqli同理，用mysqli_query()执行这条语句就行。

2. 隔离监控查询的读模式 #

监控查询一般不需要强一致性的数据，完全可以让它用快照读，避免和业务的排他锁冲突：

• 给监控会话设置READ COMMITTED隔离级别：SET SESSION transaction_isolation = 'READ COMMITTED';，这样InnoDB会用最新的快照返回结果，不会触发锁等待。
• 还可以给监控查询加执行时间限制，避免慢查询拖垮资源：

SELECT COUNT(started) FROM your_table WHERE your_condition /*+ MAX_EXECUTION_TIME(2000) */;

这个提示会强制查询在2秒内终止（MySQL 5.7+支持）。

3. 用汇总表彻底隔离监控查询 #

如果监控的统计频率不需要实时到秒级，最省心的办法是维护一个汇总表，定时更新统计数据，监控直接查这个小表就行：

1. 创建汇总表：

CREATE TABLE task_monitor_stats (
    id INT PRIMARY KEY AUTO_INCREMENT,
    started_count INT DEFAULT 0,
    last_updated DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 初始化一条记录
INSERT INTO task_monitor_stats (started_count) VALUES (0);

2. 用MySQL事件调度器定时更新：

-- 先开启事件调度
SET GLOBAL event_scheduler = ON;

-- 创建每分钟更新一次的事件
CREATE EVENT update_task_stats
ON SCHEDULE EVERY 1 MINUTE
DO
    UPDATE task_monitor_stats
    SET started_count = (SELECT COUNT(started) FROM your_task_table WHERE started = 0)
    WHERE id = 1;

3. 监控查询直接查汇总表：

SELECT started_count FROM task_monitor_stats WHERE id = 1;

这个方案几乎不会对核心业务产生任何影响，监控查询也快得飞起。

4. 进阶：读写分离（如果有资源） #

如果你的业务量已经上来了，搭建主从复制是长期解决方案：主库专门处理核心业务的SELECT ... FOR UPDATE和UPDATE事务，监控查询全部放到从库执行，彻底隔离资源。不过这个需要额外的服务器资源，适合有一定运维能力的场景。

额外注意点 #

• 核心业务的事务一定要尽量短！SELECT ... FOR UPDATE之后立刻执行UPDATE，然后马上提交事务，减少锁的持有时间，这比任何优先级设置都管用。
• 可以用SHOW ENGINE INNODB STATUS;查看锁等待情况，验证优先级设置是否生效。

内容的提问来源于stack exchange，提问作者Keyu Gan