cpu 很高的問題：
cpu消耗過大有慢sql造成,慢sql包括全表掃描，掃描資料量太大，記憶體排序，磁盤排序，鎖爭用等
臨時解決辦法有：殺掉，增加索引，優化陳述句，表資料量過大的進行分割,暫停慢查詢的模塊
長期辦法：快取、搜索引擎、優化陳述句，
鏈接數問題：可能是查詢沒有事務注解，或者有特殊的事務注解導致，通過分析當前行程中一直存在的陳述句來找問題，
-
select * from information_schema.INNODB_TRX
如果查看有很多行程都是運行中，如果一直是運行中，那需要殺掉
select CONCAT('KILL ',id,';') FROM information_schema.INNODB_TRX where ...
2、 select * from information_schema.`PROCESSLIST` where info is not null;
現象sql執行狀態為:sending data,copying to tmp table,copying to tmp table on disk,sorting result,using filesort,locked;就有問題了，
a.sending data:sql正從表中查詢資料，如果查詢條件沒有適當索引，會導致sql執行時間過長
b.copying to tmp table on disk:因臨時結果集太大，超過資料庫規定的臨時記憶體大小,需要拷貝臨時結果集到磁盤上
c.sorting result,using filesort:sql正在執行排序操作，排序操作會引起較多的cpu消耗，可以通過添加索引，或減小排序結果集
不同的實體規格iops能力不同，如，iops為150個，也就是每秒能夠提供150次的隨機磁盤io操作，所以如果用戶的資料量很大，記憶體很小，因iops的限制，一條慢sql就有可能消耗掉所有io資源，而影響其他sql查詢，對于資料庫就是所有的sql需要執行很長時間才回傳結果集，對于應用會造成整體回應變慢，
3、臨時表最大所需記憶體需要通過tmp_table_size=1024M設定
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/150752.html
標籤：AI
上一篇：求至少用了供應商“S1”所供應的全部零件的工程號 的兩種解法
下一篇：JDBC概述