数据库水位线的概念大家应该都有所了解，以前我个人觉得这个基本上是纯理论的，跟我们实际开发写sql好像没什么关系。但是在解决一次慢sql的过程中遇到了水位线的问题。
问题现象：
功能出现慢查。慢查sql为 DELETE FROM tb_cust_search_task_detail WHERE task_id = 2024;
问题分析：
大家看了这个sql估计第一反应都是数据量太大了所以导致了慢查，而且会员检索确实存在数据量很大的问题。所以第一个冒出来的解决方案就是分批删除。
然后我就看了下大概多少数据量能导致这样的慢查
一个任务下才3万多个明细就能导致删除超过5分钟？？当时有点怀疑，不过我还是没有细究，还是按照分批删除敲代码了。
敲完代码当然就是要测试下速度， 在sqladmin里查发现SELECT * FROM tb_cust_search_task_detail WHERE task_id = 2024 LIMIT 10000 居然查不出来，超过30秒了。。。。。
EXPLAIN看下
扫描行数居然近亿了，总量不是才3万多么，也用到索引了，为什么rows值还是这么大？？？ 然后看了比这个数量多的其他task_id的执行计划都是正常的。。
然后我就各种百度了下，越看越觉得可能高水位线的问题。看了下面的背景大家应该都知道为什么了
（这里说下这个task_id的背景，这个task_id是个周期性任务，每个半小时就会重新检索一遍，然后把之前的全部delete掉，再insert。这样就是做很频繁的delete，insert）
那后面就是要解决怎么降低这个水位线的问题，如果解决不了，就是改成分批删除一样还是慢查。找了DBA一起讨论这个问题，dba给的建议就是让我加个单独的task_id索引，理由单独的索引更好查询更快（可惜后面mysql没有选用这个索引），顺便他做下表重组，降低高水位线。
重组之后的执行计划，就很正常了
问题的解决方案：
1. 提交脚本给dba，让dba进行表重组，解决目前高水位线的问题
2. 针对于周期性的检索任务，不再采用先全部delete，再insert。不然后面还是有高水位线的问题。 新的方式是 ：重新检索的数据跟老的对比，该insert的insert，该delete的delete
3. 针对于页面功能重新检索，编辑的地方，需要删除检索明细的（这种删除次数不是很多的）。改成分批删除
如果很频繁的做delete和insert的时候，可能就要考虑下会不会也存在这种隐患问题。