很多场景下，我觉得加索引这个其实都不能算是优化。
多年前听到一个故事说一个DBA去了银行，回来被一个银行里面称之为大神。DBA的同事们说来给我们讲讲你怎么优化的？该DBA说，实在说不出口啊。我仅仅是加了一个索引而已。而已，而已，而已。
我们在工作中有两类最常见：一类是没建立索引，比如我刚才说的。这种连开发都知道应该建立索引。一个几亿的表，一查就慢，开发自己也知道不建立索引说不过去了。都会主动的加对应的索引。
今天我还遇到一个问题，开发过来说建立个索引吧。我说你看看这个逻辑呢？开发看后直摇头，这种没有用。
那么就是我们说的第二类。就是索引在那里，但是select的时候没用他。比如select * from t where a!='完成'。因为完成和未完成都不少。一般来说索引也建立在不去经常修改的列上。少初级开发会写出上述的SQL，因为他理解是查找未完成的就是查找全部未完成的。语法上没错就行。至于是不是看看3年前未完成的要不要处理？他不管。如果问他要不要每次都看看一年前的未处理？智商正常的通常会想想说，应该不用，那么就未处理的不用每次都去看。但是我们也不能排除这个世上就有一根筋的，他们会说要的，就是从最开始的那条做起。（这种是背着牛头不认账的，可能心里知道错了，但是嘴上一定死扛）遇到后者这种，我的建议是不要继续说下去了。不在一个世界中。
今天这个处理未完成的场景，我建议加个时间，每次检查看看一个月内有没有未完成。其实这种每5分钟的定时任务，每次看当天有没有就足够了。这样改了以后性能大概提升了20倍左右。不过这种太过基础，我依然觉得这种都不能算是优化。感觉是我大学刚毕业时候处理的一样。到2022年了，这种问题其实在全国依然很普遍。
昨天晚上在TiDB的版主会上，大家群情激奋的讨论优化器，都很专业。只是看到SQL时候，我觉得我都心疼优化器，这写的实在是不讲道理。论优化器而言大家公认Oracle做的最好，那么没有Oracle那么强大优化器的数据库我们就要好好的去写一些质量高的SQL才行。SQL的质量就是决定了系统的质量。
