MySQL不断 crash 是怎么回事? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
Great Sites on MySQL
推荐管理工具
MySQL 相关项目
MySQL不断 crash 是怎么回事?
11:52:32 +08:00 · 7052 次点击
我在 1G 内存的 linode 上跑了个 Django 站: 数据库是 MySQL 5.5, 存储引擎是5.5开始默认的 InnoDB. 一般同时在线用户数不超过20.我每天会收到几十次 Django 发来的出错邮件, 内容都是各种数据库查询失败:......OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)")但这些查询都是正常的查询, 本地调试从来没有失败过, 只是在服务器上偶尔会失败.我自己访问网站时, 也时不时会遇到500错误, 但一般刷新下又好了. 接着就会收到上面的邮件.偶尔也有网站挂掉起不来的情况, ssh 到服务器, 发现 mysql 服务停止了, 启动就好了.我很不解, 数据库明明跑得好好的, 访问量也不大, 为什么会时不时中断呢?看了下 MySQL 的 error.log , 发现原来数据库在频繁的 crash . 见帖子最后.大部分时候可以自动恢复, 但是也会出现恢复时分配内存失败, mysql 挂掉, 从而导致网站挂掉的情况.最近我反复调整 my.cnf 的参数, 但是问题一直没有得到彻底解决.请问有人遇到过类似的问题吗? 能否提供点思路?==================MySQL error.log=====================:26:10 InnoDB: The InnoDB memory heap is disabled:26:10 InnoDB: Mutexes and rw_locks use GCC atomic builtins:26:10 InnoDB: Compressed tables use zlib 1.2.3.4:26:10 InnoDB: Initializing buffer pool, size = 180.0M:26:10 InnoDB: Completed initialization of buffer pool:26:10 InnoDB: highest supported file format is Barracuda.InnoDB: Log scan progressed past the checkpoint lsn :26:10
InnoDB: Database was not shut down normally!InnoDB: Starting crash recovery.InnoDB: Reading tablespace information from the .ibd files...InnoDB: Restoring possible half-written data pages from the doublewriteInnoDB: buffer...InnoDB: Warning: database page corruption or a failedInnoDB: file read of space 0 page 15686.InnoDB: Trying to recover it from the doublewrite buffer.InnoDB: Recovered the page from the doublewrite buffer.InnoDB: Warning: database page corruption or a failedInnoDB: file read of space 0 page 49.InnoDB: Trying to recover it from the doublewrite buffer.InnoDB: Recovered the page from the doublewrite buffer.InnoDB: Doing recovery: scanned up to log sequence number :26:13
InnoDB: Starting an apply batch of log records to the database...InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed:26:13
InnoDB: Waiting for the background threads to start:26:14 InnoDB: 5.5.34 log sequence number :26:14 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306:26:14 [Note]
- '127.0.0.1' resolves to '127.0.0.1';:26:14 [Note] Server socket created on IP: '127.0.0.1'.:26:15 [Note] Event Scheduler: Loaded 0 events:26:15 [Note] /usr/sbin/mysqld: ready for connections.Version: '5.5.34-0ubuntu0.12.04.1-log'
socket: '/var/run/mysqld/mysqld.sock'
port: 3306
35 回复 &| &直到
08:00:00 +08:00
& & & 12:31:40 +08:00 via iPhone
服务器内存不够。
& & 13:07:36 +08:00
:26:10 InnoDB: Initializing buffer pool, size = 180.0M 如果你用innodb 这个值简直就不可想象啊！
& & 14:04:17 +08:00
@ 字面上的提示来说, 确实是内存不足. 但是没道理啊, 这么点访问量, 1G 的内存, 不至于不够吧?
& & 14:06:48 +08:00
@ 太少了吗, 能否说详细点? 因为之前经常出现因为内存不足导致数据库 crash 后无法恢复的情况, 于是我就把这个值调小了. 我用 mysqltunner 检测了下, 貌似这项提示是 OK 的.
& & 14:17:51 +08:00
曾遇到过类似的情况，对mysql不是很懂，把当时的步骤总结一下，希望帮到楼主：环境：512M内存的vps，mysql 5.6，搭了wordpress问题：mysql能启动，wordpress一被访问，数据库就crash尝试1：将innodb_buffer_pool_size=128M 改为5M，wp可以访问了，只是坚持不了多久还会down尝试2：调整以下参数至：performance_schema_max_table_instances=600table_definition_cache=400table_open_cache=256这时mysql启动后内存就只占用40–60M内存了以下是5.6默认的设置，会占用至少400M的内存，可能是导致crash的原因performance_schema_max_table_instances 12500table_definition_cache 1400table_open_cache 2000尝试3：经过尝试2后，问题解决了。但一个月后随着文章的增多，数据库又crash掉，直接动态扩展了vps内存到1G 问题彻底解决综上感觉内存不足是最可能的主因
& & 14:19:44 +08:00
第一感觉是内存不够，但是感觉你bp设的也不大的。。贴下完整的mysql error log吧。top命令，按M，查看各个进程内存使用情况。
& & 14:55:59 +08:00
@ =========================完整的 error.log:说明: 这台 linode 上还给一个同学跑了个 discuzz 论坛, 日志中可以看到ultrax相关的表 crash 了::24:35 [ERROR] /usr/sbin/mysqld: Table './ultrax/pre_forum_promotion' is marked as crashed and should be repaired开始我怀疑是这个discuzz 导致的. 但我把它关掉观察了一段时间, 数据库还是会不断崩溃, 所以和这个关系不大. 而且,在有这个 discuzz 之前,我也会经常收到出错邮件.=========================完整的 my.cnf:=========================htop 的内存占用截图:
& & 15:48:56 +08:00
@ 如果你的表用的innodb存储引擎，你需要调整innodb buffer size的大小。你贴一下你的my.cnf文件内容吧。这个肯定只配置问题。
& & 16:05:52 +08:00
@ htop里，mysqld进程那么多？另外，我个人觉得，vps 1g，可能 innodb_buffer_pool_size
值可以调的小点。比如32M？虽然你有1g内仓，然后innodb_buffer_pool_size
=128M，但是其他也有内仓分配，比如 key_buffer
= 64Mquery_cache_size
= 64Mtmp_table_size = 250M总共加起来就不少了。另外你的服务器也不止mysql，还有别的服务要占内存。以上只是我个人推测。。。
& & 16:43:38 +08:00
看其他进程是不是突然占满剩余MEMORY,导致mysqld overcommit
& & 17:08:22 +08:00
@ error log里面不是报错嘛，一些表坏了，问题大概在这里
& & 18:34:43 +08:00
明显是内存不够呀...你 top 下看看还有什么东西特别占内存吧
& & 19:03:56 +08:00
@ my.cnf 在这里:
& & 19:14:14 +08:00
@ 1. htop 中, mysql 的进程有20多个, 我也不太明白这个是由哪个参数决定的2. innodb_buffer_pool_size 之所有设置成这么多, 是因为我用mysqltuner这个工具测试了一下我的配置, 结果如下:-------- Performance Metrics -------------------------------------------------[--] Up for: 27m 23s (19K q [11.997 qps], 941 conn, TX: 48M, RX: 4M)[--] Reads / Writes: 96% / 4%[--] Total buffers: 344.0M global + 2.7M per thread (20 max threads)[OK] Maximum possible memory usage: 397.8M (40% of installed RAM)[OK] Slow queries: 0% (11/19K)[OK] Highest usage of available connections: 35% (7/20)[OK] Key buffer size / total MyISAM indexes: 64.0M/1.5M[OK] Key buffer hit rate: 100.0% (456K cached / 7 reads)[OK] Query cache efficiency: 40.7% (6K cached / 15K selects)[OK] Query cache prunes per day: 0[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)[OK] Temporary tables created on disk: 23% (191 on disk / 827 total)[OK] Thread cache hit rate: 99% (7 created / 941 connections)[OK] Table cache hit rate: 25% (450 open / 1K opened)[OK] Open file limit used: 62% (641/1K)[OK] Table locks acquired immediately: 100% (10K immediate / 10K locks)[OK] InnoDB data size / buffer pool: 146.0M/180.0M这里面最后一条,提到我的数据库大小是146M, 而我的 buffer size 要比这个大才行. 因此我才设置为180M. 如果设置成小于146M 的值, 数据库 crash 之后, 就会分配内存失败, 起不来.3. 其他的几个参数, 我也是根据 mysqltuner 的建议修改的.
& & 19:32:37 +08:00
@ 从 htop 的显示看, 整个系统的内存确实几乎耗尽. 但其中, mysql 占了12%左右, django 占了4%左右, 其他都很少. 不知道问题出在哪里.
& & 19:34:48 +08:00
@ 我前面的回复里说了, 这个 linode 上还有个 discuzz, 我也注意到它的表崩溃了. 我有几天关掉了这个 discuzz, 但是问题还在. 可见不是它的问题. 而且,就算修复了崩溃的表, 过不多久, 这些表又崩溃了.所以我懒得管它了.
& & 20:01:16 +08:00
@ 他是很多mysqld，每个10.9%啊，连swap都快慢了，这是爆内存的节奏啊
& & 20:07:53 +08:00
@ htop虽然显示20多进程,但是内存的占用并不是每个都那么多, 是总共12%左右.
& & 20:23:14 +08:00
@ htop虽然显示20多进程,但是内存的占用并不是每个都那么多, 是总共12%左右.1. 如何看出是总共12%？我觉得是单个10。9%，然后20个就是200%吧。。。free -m 结果看下？2. 为什么我看到我服务器上只有一个mysqld进程，你为什么会那么多？大家为什么对这个没疑问？大家都是那么多进程的？3. mysql配置参数，看你的意思，都是根据 mysqltuner 这个工具来配置的。这个工具有考虑到你其他情况吗（比如你开了discuz）？他的这个测试的前提条件是不是这个服务器只跑mysql呢（事实上你还跑了其他，比如web server）？4. 这里面最后一条,提到我的数据库大小是146M, 而我的 buffer size 要比这个大才行. 因此我才设置为180M. 如果设置成小于146M 的值, 数据库 crash 之后, 就会分配内存失败, 起不来.按你的说法，buffer_pool必须比数据库大。。。那假如我10g的数据库，我buffer_pool要开到10g吗？ps：我在我这边线上环境，buffer_pool只开了128m，我的db size肯定大雨128m（事实上是10多g）。当然，我没说我的buffer_pool配置的正确，因为我看网上都说要配置的比较大。但至少我这边运行的还好，也没出什么问题，至少没crash。当然，我这边也不是什么高并发的查询。以上仅供参考。。。
& & 20:40:49 +08:00
swap 都这样了，这db性能还能忍受的啊同一机房再买个vps单独跑mysql算了
& & & 20:45:32 +08:00 via iPad
你的表是 InnoDB 还是 MyISAM 的？InnoDB 的话是不需要开 key_buffer 的。
& & 21:00:55 +08:00
我突然想到知乎也时不时的500。刷新一下就好了。。
& & 22:07:40 +08:00
@ 那个htop里mysqld可能共享memory，不是累加的。按照你说的来看，mysqld和django并没有占多少内存。你能top -& shift-f -&n 列出占用大户么？
& & 22:18:52 +08:00
@ 多出来的不是进程，是mysql处理请求的线程。既然表修复好问题仍然出现，你看下磁盘有没有问题。
& & 05:44:47 +08:00
@ 用的InnoDB, 默认的. 好的,我把 key_buffer设置去掉
& & 05:55:41 +08:00
1. 我截图里当时是10.9%, 总共也是这么多. 内存怎么可能用到200%呢...2. 我用的是 htop 命令查看的, 它是更高级的 top, 会显示子进程. 你如果用 top 看,只会看到主进程.3. mysqltuner 可以根据你的机器配置以及过去24小时的运行情况, 给你的 mysql "体检".4. 如果访问量不高, 不会有问题吧. 但是设置成比数据库大, 是确保安全的做法.
& & 05:56:03 +08:00
@ 上一条是回复给你的.
& & 05:57:47 +08:00
@ 关键是其实访问量并不大,一个小站而已. 肯定是有问题, 没必要盲目堆硬件.
& & 05:59:08 +08:00
@ 空间是够的, 用了50%多点. 还要检查什么? 损坏吗?
& & 06:01:07 +08:00
@ top 里的内存占用情况:
& & 07:40:37 +08:00 via Android
* 看 errorlog，不是mysql自己的問題。似系統無法分配足夠內存，oom機制殺掉了mysql進程，可以檢查 系統日誌 syslog參考
在 crash 時也許有其它進程快速佔用了比計劃多得多的內存 （比如python, php都是潛在的內存大戶，如果還有文件io操作。。）*
順便建議mysqltuner 的測試要啟動一段時間後再進行Up for: 27m 23s 這時可能cache沒warmup，hit rate會偏低。不過僅僅看數字這份my.cnf沒受這個影響。* 這裡還有個比較長比較全面討論低配機器的mysql配置檢查。* 如果短期訪問量不會增加，又沒有慢速查詢，my.cnf裡 max_connections可以再降低點。
& & 08:35:48 +08:00
@ 哇,都是干货啊, 多谢:)
& & 11:09:47 +08:00
@ OK, MEM占有也就前几个进程累加起来的，剩余的多数都被内核申请为磁盘CACHE了，所以top上面有个used mem已经满了的假象。可能需要观察到CRASH那一刻，各个进程的情况，个人觉得你可以限制php和python的实例创建上限。
& & 16:36:46 +08:00
@ @多谢二位, 你们的分析引导我找到了问题所在.我的网站上有几个实时统计的页面, 需要联合查询大量数据, 每次查询都好慢. 由于太卡, 我用的不多, 也一直没太在意.今天早上特地看了下,每次点击统计页面, mysql 某个进程的 CPU 就会彪到100%多, 整个服务器都很卡顿. 应该就是它导致了 mysql 崩溃.我去掉了统计页面, 今天观察了一天, 目前为止没有再收到任何 mysql 错误.现在想来, 这几个页面因为很卡,所以我自己很少点, 都被我遗忘了. 我想点过的用户也不想点第二次. 但是每次有新用户进来, 他可能在无意识的情况下随手点了它, 这就导致 mysql 崩溃. 根据我目前网站上的用户数, 我每天收到的出错邮件次数, 也差不多符合这个假设.当然,目前观察的时间还太短,不能下结论. 但是也应该差不多.这个问题一度让我怀疑 mysql 的性能, 现在看来, 问题出在我自己的不当查询上面. 惭愧.
& & 03:01:15 +08:00
@，这个配置需要根据你目前机器的资源和产品的应用来做调整，我简单的看了一下，这个配置文件不是很好，default-storage-engine = innodb事例几个需要优化innodb_buffer_pool_size = 180M #通常为物理内存的50%，或者70-80%tmp_table_size = 250Mmax_heap_table_size = 20M #这两个选项的值最好是相等的。只有cpu太高，那就要优化SQL了，另外估计你代码的严谨度不够，比如一些地方需要做合并请求，总不能点一次查询一次。如果需要额外的付费的服务，请联系我哈！
& · & 2263 人在线 & 最高记录 3762 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 19ms · UTC 11:49 · PVG 19:49 · LAX 04:49 · JFK 07:49? Do have faith in what you're doing.当前网站的七日平均日IP为2900，PageView为3.8万左右。网站A用的database目前有39个表，记录数60.1万条，占空间45MB。按这个数据，Mysql不可能占用这么高的资源。
于是在服务器上运行命令，将 mysql 当前的环境变量输出到文件 output.txt：
d:\web\mysql& mysqld.exe --help &output.txt
发现 tmp_table_size 的值是默认的 32M，于是修改 My.ini, 将 tmp_table_size 赋值到 200M:
d:\web\mysql& notepad c:\windows\my.ini
tmp_table_size=200M
然后重启 MySQL 服务。CPU 占用有轻微下降，以前的CPU 占用波形图是 100% 一根直线，现在则在 97%~100%之间起伏。这表明调整 tmp_table_size 参数对 MYSQL 性能提升有改善作用。但问题还没有完全解决。
于是进入 mysql 的 shell 命令行，调用 show processlist, 查看当前 mysql 使用频繁的 sql 语句：
反复调用此命令，发现网站 A 的两个 SQL 语句经常在 process list 中出现，其语法如下
SELECT t1.pid, t2.userid, t3.count, t1.date
FROM _mydata AS t1
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid
LEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pid
ORDER BY t1.pid
LIMIT 0,15
调用 show columns 检查这三个表的结构 :
mysql& show columns from _
mysql& show columns from _
mysql& show columns from _mydata_
终于发现了问题所在：_mydata 表，只根据 pid 建立了一个 primary key，但并没有为 userid 建立索引。而在这个 SQL 语句的第一个 LEFT JOIN ON 子句中：
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid
_mydata 的 userid 被参与了条件比较运算。于是我为给 _mydata 表根据字段 userid 建立了一个索引：
mysql& ALTER TABLE `_mydata` ADD INDEX ( `userid` )
建立此索引之后，CPU 马上降到了 80% 左右。看到找到了问题所在，于是检查另一个反复出现在 show processlist 中的 sql 语句：
SELECT COUNT(*)
FROM _mydata AS t1, _mydata_key AS t2
WHERE t1.pid=t2.pid and t2.keywords = '孔雀'
经检查 _mydata_key 表的结构，发现它只为 pid 建了了 primary key, 没有为 keywords 建立 index。_mydata_key 目前有 33 万条记录，在没有索引的情况下对33万条记录进行文本检索匹配，不耗费大量的 cpu 时间才怪。看来就是针对这个表的检索出问题了。于是同样为 _mydata_key 表根据字段 keywords 加上索引:
mysql& ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )
建立此索引之后，CPU立刻降了下来，在 50%~70%之间震荡。
再次调用 show prosslist，网站A 的sql 调用就很少出现在结果列表中了。但发现此主机运行了几个 Discuz 的论坛程序， Discuz 论坛的好几个表也存在着这个问题。于是顺手一并解决，cpu占用再次降下来了( 附注：关于 discuz 论坛的具体优化过程，我后来另写了一篇文章，详见：千万级记录的 Discuz! 论坛导致 MySQL CPU 100% 的 优化笔记http://www.xiaohui.com/dev/server/-discuz-mysql-cpu-100-optimize.htm)。
解决 MYSQL CPU 占用 100% 的经验总结
增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。 这是 mysql 官方关于此选项的解释：
tmp_table_size
This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory.
对 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的条件判断中用到的字段,应该根据其建立索引 INDEX。索引被用来快速找出在一个列上用一特定值的行。没有索引，MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大，花费时间越多。如果表对于查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要考虑所有数据。如果一个表有1000行，这比顺序读取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。
根据 mysql 的开发文档，索引 index 用于：1，快速找出匹配一个WHERE子句的行
2，当执行联结(JOIN)时，从其他表检索行。
3，对特定的索引列找出MAX()或MIN()值
4，如果排序或分组在一个可用键的最左面前缀上进行(例如，ORDER BY key_part_1,key_part_2)，排序或分组一个表。如果所有键值部分跟随DESC，键以倒序被读取。
5，在一些情况中，一个查询能被优化来检索值，不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀，为了更快，值可以从索引树被检索出来。
假定你发出下列SELECT语句：
mysql& SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
如果一个多列索引存在于col1和col2上，适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上，优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。
mysql实例cpu超过100%分析
MySQL占用内存与CPU过高测试与解决办法
Mysql占用CPU过高如何优化，如何解决
MySQL服务器CPU跑满100%的情况分析
MySQL5.6.12造成CPU的使用率 2000%的原因
解决MySQL CPU占用100%的经验总结
没有更多推荐了，当前位置：
→ mysql数据库密码修改图文教程
本类常用软件
下载量：584212
下载量：419759
下载量：366966
下载量：365708
下载量：325899
mysql数据库密码修改图文教程
2:17:33&&出处：&&&人气：1351次&&&&字号：&&&&
东坡下载 & 分享互联网
Copyright(C)
www.uzzf.com All Rights Reserved! 网站备案/许可证号:鄂ICP备号-1MySQL占用CPU及内存高解决案例_数据库技术_Linux公社-Linux系统门户网站
你好，游客
MySQL占用CPU及内存高解决案例
来源：Linux社区&
作者：liangey
故障：& & & 晚上大概7点钟左右，收到播放中心投诉，说视频播放很慢，加载很久不出来。一开始，哥以为是tomcat服务又挂了。所以到tomcat服务器上查看下catalina.out输出日志。却没发现任务错误信息。
分析：& & &
想了想，视频加载慢，会不会是数据库问题呢？果断上mysql数据库(从库)看下top如下：&
PID USER& & & PR& NI& VIRT& RES& SHR S %CPU %MEM& & TIME+& COMMAND&
&37258 mysql& & 20&
0 17.2g& 12g 5032 S 769.5 81.3&
4383:29 mysqld
没想到cpu居然达到769%了！& &
然后进入mysql的慢查询语句的目录下面，看下slow.logselect count(*) as col_0_0_ from card_received cardreceiv0_ where (cardreceiv0_.statusCode='1' or cardreceiv0_.statusCode='2') and (cardreceiv0_.ownerCardNum='6209' or cardreceiv0_.ownerPhoneNum='') and cardreceiv0_.readStatus=0\G;
发现这条查询语句耗时5秒左右，但是slow.log里面全部是这条语句。所以我觉得很可疑。再用explain分析下看mysql& explain select count(*) as col_0_0_ from card_received cardreceiv0_ where (cardreceiv0_.statusCode='1' or cardreceiv0_.statusCode='2') and (cardreceiv0_.ownerCardNum='6209' or cardreceiv0_.ownerPhoneNum='') and cardreceiv0_.readStatus=0\G; & & explain结果： ************************** 1. row *************************** & & & & &
id: 1 & & & & &
select_type: SIMPLE & & & & &
table: cardreceiv0_ & & & & &
type: ref possible_keys: readStatus,ownerCardNum,statusCode,ownerPhoneNum & & & & &
key: readStatus & & & & &
key_len: 5 & & & & &
ref: const & & & & &
rows: 2394190 & & & & &
Extra: Using where 1 row in set (0.00 sec) & ERROR:& No query specified
居然扫描了：2394190行。。。。&
最后跟开发沟通后，因为这边表数据并不重要。故将一些旧数据情况了，表示已经清空了200万行！最后mysql的cpu终于降下来了。。。不过要彻底解决问题，仍需要优化语句，建立索引哪。。不然数据多了，肯定还会出问题的。好了，此次故障也仅仅给提供一些解决问题的思路。具体问题还是需要具体分析的。
本文永久更新链接地址：
相关资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款}