减少上下文切换的关键：控制并发连接数
MySQL 的上下文切换开销主要来自频繁的线程创建、销毁和调度，尤其在高并发短连接场景下尤为明显。默认的 thread_handling = one-thread-per-connection 模式会让每个新连接启动一个独立线程，连接数一多，内核调度压力陡增。应优先启用线程池机制（需 MySQL 5.6+ 企业版）或使用连接池中间件（如 ProxySQL、MySQL Router），让少量工作线程复用处理大量连接请求。
合理配置线程相关参数
即使不启用线程池，也能通过调优降低切换频率：
max_connections：设为业务峰值预估的 1.2–1.5 倍即可，避免过度预留；过高会占用内存并加剧调度负担 wait_timeout 和 interactive_timeout：建议调低至 60–180 秒，及时回收空闲连接，防止“僵尸连接”长期占线程 thread_cache_size：设为 CPU 核心数的 2–4 倍（如 8 核设为 16），使断开的连接线程可缓存复用，避免反复创建销毁应用层配合：复用连接 + 异步化
数据库连接本身是昂贵资源，应用端不当使用会放大上下文切换问题：
禁用“每次查询都新建连接 + 立即关闭”的模式，改用连接池（如 HikariCP、Druid），保持连接长生命周期 对非强一致性读操作（如报表、日志查询），考虑异步执行或批量合并，减少单位时间内的连接频次 避免在事务中混入耗时的外部调用（如 HTTP 请求、文件读写），防止线程长时间阻塞，拖慢整体调度效率识别与验证优化效果
优化后需用实际指标验证是否真减少了上下文切换：
观察 SHOW STATUS LIKE 'Threads_created'：数值增长变缓，说明线程复用增强 检查系统级指标：vmstat 1 中的 cs（context switch） 列，对比优化前后每秒切换次数 用 perf record -e sched:sched_switch -p $(pgrep mysqld) 抓取调度事件，分析线程阻塞热点
