阿松嘚嘚嘚-数据库篇4-查询优化不简单（下）

老于：“其实，创建索引，可以有下面几个原则。比如，字段数据具有唯一性，就得建索引；频繁作为WHERE查询条件或者GROUP BY ORDER BY的，也得建索引；多表连接，更得在连接字段上建索引；被DISTINCT修饰的字段，还得建索引”

阿松：“一句话，出镜率高或者筛选度高的字段就需要索引”

老于：“不错，所以我们也可以知道哪些情况不要建索引”

阿松：“让我来对照着捋一捋，字段数据没有唯一性，基本就是有限的几个数据，不要建；很少使用的字段，不要建。”

老于：“还有，如果表的数据量很小，那也不用建，想想小品上那句话‘你就捐几百块钱，人家就大车小辆来家里采访，你这都不够油钱’，如果一个字段的值被频繁修改，也不要建。”

阿松：“建，还是不建，这是个问题！”

老于：“还有一个问题就是，建了也白建，做了无用功”

阿松：“此话怎讲？”

老于：“索引会有失效的情况，假如我们给A建了索引，比如，用了表达式计算，写成了A+1=xxx,这种就失效，你得写成A=xxx-1；A上用了函数，比如SUBSTRING(A)，也会失效；A LIKE ‘%t’也会失效；还有啊，索引字段和NULL NOT NULL做判断时，或者通过OR连接时，如果有一个字段没有加索引，所有字段索引都会失效。”

阿松：“别的都好理解，LIKE ‘%t%’为啥会失效，这个我原来经常用，匹配部分字符串太好用了”

老于：“你可以用查字典来想象，如果你要查T开头的字，直接翻开字典目录，找T开头的那一页索引就行了，但是如果你只知道你要查的字，中间有个拼音是T，你去哪一个索引页翻呢？只能从头开始一个个查了，索引就没用了。”

阿松：“原来如此”

老于：“第三步，就是加一层，缓存，比如Redis和Memcached作为缓存，这个例子很多，比如手机收到的验证码，就可以用Redis作为缓存，设置一个失效时间，在失效时间范围内，通过手机号和验证码在Redis里进行查找，找到了，就可以登陆了。”

阿松：“我说为啥手机验证码有个失效时间呢，原来就是缓存的时间”

老于：“第四步，就是架构的升级，采用主从架构，数据库拆分成主库和从库，主库接受写，从库接受读。当然这个具体操作起来就要考虑一致性问题了。”

阿松：“我估计，我们学校的选课系统加个缓存就够了，把校选的公共课放到缓存里，应对全校的高并发读，专业课可以不用，因为QPS小”

老于：“你啊，现在还是处于纸上谈兵的阶段，但是有这种思路还是对的。选课系统和排课系统优化的代价太高，不是因为难，而是优化后的收益小，因为它们只在一年内极短的时间内会有高QPS，这种属于就是你想干，也可能干不了的事情呦”

阿松：“你这老给我灌输什么思想，我可是要做架构师的男人。所以，我还是琢磨琢磨中午吃啥吧，下午再试。话说，老哥，你买菜了么？”

老于：“买了，一会儿外卖的就来了，话说，架构师先生，你想过数据库的并发访问机制么？这和取外卖有点像”

阿松：“我现在只想吃饭，吃饭时候你再给我讲吧，取个外卖都能有这么多事。。。”