前段时间，偶然看到这么一个面试题，心里那个滋味，哎，啥也不说了。还记得以前面试的时候也碰到了类似的问题，怎么回答的印象不是很深刻了，但是回答的绝对不咋地。呼啦啦来了几句，然后
总是有种，似有千言万语，但是不知道说啥的样纸。。
网上随便一搜，哗啦啦来了四五十条什么数据库注意事项啊，索引的使用啊。仔细看看，嗯！
然后，我刚刚看了啥？哦，有索引失效。索引字段前面like的时候不能加“%”，不然索引失效，不走索引，查询就慢了。
然后其他呢？其他好像都是废话，不是啥优化，似乎都是一些不应该犯的低级错误？反正感觉就是眼睛看进去，后脑勺出去。吃个饭，嗯，没啥子印象了。
小小回顾下自己使用数据库的情况，咦，咱好像也能勉强说出个1,2,3条来，虽然没人家总结的多，但是感觉记起来就舒服多了。
好了，咱们来闲聊闲聊。分类也懒得加了，写到哪算哪吧~
咱们先从建表开始，嗯，数据库的索引会提高查询效率不错，不过数据表的基础还是数据，数据量或者数据大小减少了，查询速度也是会有一定的增加的哦。
由此可得，建立数据库表的时候，首先要尽量按需索取，尽量限制字段的空间大小。比如，你这一个字段存的是身份证号，那么18位也就够了，是在不放心，加上个一两位问题也不大，没必要使用默认的大小。
其次就是一些字段经常为空，也就是null，这样真的是不占用空间么？没错null是不需要占用空间，但是人家会多占用一个标志位啊，而且在查询判断的时候还需要进行处理，如果索引可以为null的话，BTree是不存储null的，如果null多了的话，也会影响查询效率的。
还有一点小细节，如果数据表中某个字段为数字的话，最好设置成无符号的（unsigned），这样数据的空间就会明显增大，可能tinyInt就能满足需要，当然如果会有负数的话，可以根据实际情况来。
还想吐槽一下的就是，像remark这种文本或者json字符串啊，尽量根据实际来，别一上来就是500,1000的，能少则少，这种数据一般不会超过100-200个字的，前端做下限制，没必要留一大堆空的底盘放到数据库，这种都会无形影响查询的效率，当然，在乎不在乎又是另外一回事哈。
至于说设计表的那点事儿，看业务，看场景，看对应关系，当然，产品设计也是很重要，设计的时候最好画一下E-R关系图，以免漏了点东东，填坑累死人啊！
id主键，要设置成自增，，算了，这种普及型的就不说了。还是去聊聊索引吧。
索引，大家都知道是一个有序的树结构，查询效率是对数级别，基本上是很快的。
既然是索引是有序的树结构，像1,0,0,0，1 或者是有许多null的字段就不用单独建立索引了，没啥意义啊！
你说为啥没意义？老哥把路走窄啊！首先，BTree树是不存null的，凡是null的数据，都要一条一条扫描。至于像1,0这种数据，一半在索引这边，一半在那边，至少也要扫描一半！没啥意思啊！
“那这也能减少一部分查询啊，能快一点是一点呗!”
老兄，你是来抬杠的吧？聚簇索引，非聚簇索引了解下，回表了解下！你查询1,0这种数据总不是只要1,0啥也不要吧？不然那你直接返回得了，还查询啥啊。
所以，你这种情况是不会使用索引下移的，肯定是要走下回表的，！
扫描整个索引并查找到数据的成本比扫描全表的成本更高，优化器放弃使用索引。也就是说你这种根据索引查询，回表的时候查询数据再对比，还不如我直接查询全表效率高呢！弄啥呢，索引合着还没直接查询快，不要搞事情好不？
还有就是，创建索引的时候，不用那么实在，人家定义姓名字段的长度是50 ，你建立索引也用50个字段的长度？老兄太实诚了吧，取前15个字段怎么说也够了吧，还能有大部分人名字长度超过15？当然这个可以根据自己需要，如果是建立联合索引的话，可以在适当缩减长度，能确定数据就行！这好像叫 前缀索引 。有个印象就好，反正我用的很少很少~
一般建立索引我们使用的都是树结构。不过hash也是可以考虑的，比如，某个订单表，订单号唯一，只进行单个查询或者是in查询，这种使用hash也许会更好哦，毕竟hash一次到位，比树都快！贼溜，可惜就是不支持比较大小，索引最好还要是唯一的！
建立完数据库表，之后就是使用索引了，可以说，100个表中100个表都建立了索引，起码id主键肯定建立的唯一索引不是？
说到索引优化，第一步！嗯，百分号，哈哈哈！查询字段前面不能有【%】，否则会不走索引，你说为啥？去看BTree原理去！
索引为啥查的快？不就是根据大小顺序分层么？你一个字符串是怎么比较大小的？还不是从左往右一个字符串一个字符串的进行比较，如果加了【%】，都不确定第一个字符是啥，咋比较，只能全局扫描了。
一旦使用索引，就要牢记四个字，大小，比较！
接着说，既然比较大小，不用说，聚合方法肯定也不能用了，你对数据库索引字段进行了加减乘除，拼接什么的，索引树哪知道？最后也就走不了索引。
然后，连表查询的时候，当然，我们一般使用left join，这个是一定要加上索引的，不然整死人啊，mysql连表查询用的是啥？循环嵌套查询，如果没有索引，直接把所有数据加载到内存里面，然后一条数据一条数据的和连接的数据进行比较，，，你想一想？算了，不想了，头疼！
“对了，为啥要用left join来着？”
呃呃，这个就有点多了，建议去看下笛卡尔积去，看完之后，嗯，估计老兄就明白了。
下面再说下联合索引吧，其实也没啥，索引么，也就是比较大小，定位数据罢了。联合联合，把几个字段拼接成一起，组成索引树呗，然后进行查询，比如三个字段，姓名+年龄+居住地三个字段组成的联合索引。
查询的时候先找查询条件里面必须有姓名！其他的两个，爱有就有，有就准确点，没有就查询的结果多一点呗。
比如：select * from table where 年龄=12 and 姓名 = ‘张三’ 。
这种会走索引么？肯定会啊，不是有姓名+年龄么？
“可是这年龄不是在前面么？没法比啊！”
可是mysql查询有优化器啊，人家看到可以走联合索引，自然会把你这个顺序给调整一下，毕竟是成熟的产品了，那会那么死板！
那如果：
select * from table where 居住地=beijing 。
这种会走么？肯定不会啊！这不就和like 前面加【%】一样么，不知道开始是啥，比啥啊！还是老老实实走全表扫描吧！
先说到这吧，系统的归纳整理有空再整，反正索引使用中的皮毛也就那点事： 大小，比较！
觉得可以的话点个赞呗~
no sacrifice，no victory~
扫一扫
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
