法国多ip服务器MySQL占用CPU过高如何排查慢查询?

法国多IP服务器上MySQL的CPU占用突然拉高，和单IP环境下的排查有一个很实际的差别：你面对的可能不是同一个数据库在承受全部压力。多IP服务器上往往跑着多个站点或应用，每个站点连接的是哪个数据库、哪个库里的哪张表在拖垮CPU，如果不先做一次归属划分，直接去看全局慢查询日志，很容易被大量无关的查询记录淹没。真正有效的切入点，是先确认高CPU是哪个IP对应的业务引起的，再针对那个库做慢查询定位。

先确认高负载落在哪个数据库实例上

多IP服务器常见的部署方式有两种：所有站点共用一个MySQL实例，或者按IP或业务拆分成多个实例。如果是前者，CPU高就是整个实例的问题，排查范围相对明确。如果是后者，用top或my_top看到某个mysqld进程占着CPU不放时，先确认这个进程对应的是哪个端口或哪个数据目录。这一步看似基础，却经常被跳过。有人看到CPU告警就直接去翻慢查询日志，结果日志里记录的是另一个空闲实例的零星查询，真正吃CPU的那个库反而没有开启慢查询日志。

确认实例归属之后，第一件该做的事不是翻日志，而是用SHOW FULL PROCESSLIST看一眼当前正在跑的查询。CPU飙高的瞬间，往往有几个查询正处在Sending data或Copying to tmp table状态。把这些查询的SQL文本截取出来，和慢查询日志做对照，能快速判断高CPU是长期积累的慢查询造成的，还是某个突发的大查询瞬间把CPU打满。

慢查询日志的开启方式决定了你能不能抓到真凶

MySQL的慢查询日志默认是关闭的，long_query_time的默认值是10秒。这个默认配置在法国多IP服务器上往往不适用。跨境业务的查询延迟本身就比本地高，如果等10秒才记录，很多实际已经造成CPU压力的查询会被漏掉。建议把阈值先调到1到2秒，让日志能够捕捉到那些“不算极慢但频率很高”的查询。高频的中等慢查询对CPU的累积消耗，有时比一个偶尔出现的十秒大查询更严重。

还有一个参数值得注意：log_queries_not_using_indexes。开启它可以记录那些没有使用索引的查询，即使执行时间没有超过阈值。在多IP服务器上，不同站点可能由不同开发者维护，索引缺失的情况参差不齐。开启这个选项能帮你发现那些因为全表扫描而悄悄消耗CPU的查询。不过这个选项会让日志增长很快，建议配合log_throttle_queries_not_using_indexes做限速，避免日志文件把磁盘写满。

用聚合工具把日志从流水账变成线索

直接打开慢查询日志文件逐条看，效率极低。日志里同一个查询可能出现几十上百次，手动翻找既耗时又容易遗漏规律。用mysqldumpslow按总耗时或执行次数排序，几秒钟就能把最值得关注的查询排到前面。比如mysqldumpslow -s t -t 10会列出总耗时最高的十个查询，-s c则按出现次数排序。在多IP多站点的环境里，按次数排序往往更有价值，因为一个每次只跑0.5秒但每分钟执行几十次的查询，对CPU的持续占用可能远超一个偶尔跑3秒的报表查询。

如果服务器上能装Percona Toolkit，pt-query-digest给出的信息更细，包括扫描行数与返回行数的比例。这个比例很能说明问题：如果一个查询扫描了几万行却只返回几十行，索引缺失或索引设计不当的可能性就很大。法国多IP服务器上跑着面向欧洲用户的业务，数据量和查询模式可能和国内环境有差异，这种“扫描多返回少”的查询在跨境延迟的叠加下，对CPU和IO的双重压力会更明显。

一个关于多站点共用数据库的实际场景

曾有一个案例，法国多IP服务器上部署了几个面向欧洲不同国家的小型电商站点，共用一个MySQL实例。某天下午开始，CPU持续在百分之八九十徘徊。运维人员先看了慢查询日志，发现排在前面的都是某个站点后台的报表查询，单次执行两三秒，频率也不算高。但把这些查询的总耗时加起来，占不到CPU总消耗的合理比例。后来用SHOW FULL PROCESSLIST抓了几次现场，发现有一个查询反复出现，执行时间不到一秒，所以没有被慢查询日志记录，但它在短时间内被调用了极多次。追查下去，是另一个站点的商品列表页在某个筛选条件下触发了循环查询，每个页面请求会执行几十次单条查询。单个查询快得不够格进慢日志，但乘以请求量和循环次数之后，成了CPU的真正负担。这个案例的教训是：慢查询日志的记录阈值不能设得太宽松，否则那些“不够慢但足够频繁”的查询就会成为盲区。

优化动作要落在具体的索引和查询写法上

定位到问题查询之后，用EXPLAIN看执行计划是标准动作。重点关注type列是否出现ALL，key列是否为空，以及rows列估算的扫描行数。如果一张几十万行的表在WHERE条件上走了全表扫描，加一个合适的索引通常能让CPU占用降下来。但加索引不能只看单条查询，在多站点共用数据库的场景下，还要考虑这个索引会不会影响其他站点的写入性能。法国多IP服务器上的业务如果读写混合，盲目加索引可能把压力从CPU转移到IO上。

另一个容易被忽视的点是查询中的函数调用和隐式转换。在WHERE子句的索引列上套函数，或者关联字段的字符集不一致导致隐式转换，都会让索引失效。这类问题在多站点环境下尤其常见，因为不同站点的表可能由不同时期的代码创建，字符集和字段类型未必统一。用EXPLAIN看到key列有值但rows依然很大时，就要怀疑是不是发生了隐式转换。

总结

法国多IP服务器上MySQL的CPU排查，关键在于把“哪个实例、哪类查询、什么频率”这三个问题按顺序拆开。先用进程列表锁定正在消耗CPU的实例和查询，再把慢查询阈值调到能抓住高频中等查询的水平，用聚合工具筛出真正值得优化的那几条，最后用EXPLAIN确认索引是否被正确使用。多IP环境带来的复杂度不在于技术本身，而在于归属关系的模糊，把归属理清了，后面的动作都是常规操作。

纵横云服务器租赁，欢迎随时联系，客服联系方式：QQ3494196421，手机微信19906048601。