## 关于mysql 面试的总结(记录版)

关于mysql 面试的总结(记录版)

1. 数据库计算:
   千万不要在数据库做复杂的计算,
   尽量复杂的计算坐在cpu中;
   例如:md5(); order by Rand();

2. 表的数据量;
   单表数据量尽量不到超过1000Wz(纯int )
   如果含有char,最好不要大于500W
   这个地方业务基本上不可能纯int的.所以尽量不到超过400W

3. 合理的分库分表;
   单库尽量不要超过300-400张表;
   小的 业务线基本上不会超过300张表;
   如果表小于400张,那么还是不要做分库分表的好;(个人觉得)

4. 表字段的高效和合适
   IO高效; 全表遍历; 并发;等等
   一些具体的行业规范,暂时我还没有遇到那么严格的写法;
   例如: 单表1G的体积,500W的评估;
   单行200的字节;
   单表50个纯int的字段
   单表20个char(10)的字段
   我觉得很少有单表可以达到50个纯int字段,(个人公司业务很简单,暂时没有用到);
   我一般单表字段控制在20-30个字段之间;这样也不是很长,后期维护起来也不是很麻烦;

5. 最最最重要的也是我最容易忽略的就是 “设计三范式”

6. 拒绝大的sql,大事务,大批量;

7. 避免使用null的字段;
   null会使索引优化失效;
   null加索引的话,会浪费大量的额外的空间
   null的话复合索引会失效

8. 索引的问题;
   索引一定要明白,并不是越多的索引越好;
   索引覆盖尽量不到超过20个字段,这个地方就是我上边说的那个字段的数量;
   拼音什么的,一定要建前缀索引,一定要建!!!
   不要做索引的数学运算和函数运算;

9. big sql 和多个简单sql的对比
   传统的设计思想;
   一个sql只能在一个cpu中运算
   在高并发和大的qps中,好几秒的大的sql, 就意味着一个sql会占用一个表好几秒钟;
   建议是一个大的sql 拆分成多个小的简单的sql,而且不要在sql中写存储过程,存储过程这个东西, 用不好实在是太坑人了,讲道理这个大坑千万别踩了,后期离职之后维护起来也不是很好维护;
   小的sql,会更大的概率命中缓存的,并且减少锁表的时间,如果配合多个cpu快的飞起

10. 所有的的操作,尽量都别用;
    select * 这个可以另外的一个写法代替掉;
    你可以定一个 <Base_Column_List> 标签嘛,这个上边你写上你所有的字段,之后你用到时候调用就可以了;这样也方便一些;
    不用是因为会占用更多的内存和cpu,包括IO和宽带
    不用也是为了更安全的设计,减少表的变化带来的更大的维护成本;

11. or和 in的用法
    or的效率为O(n)
    in的效率为O(Log n)
    当n很大的时候,or 就会变得很慢很慢
    in也要注意一些限制,最大的in的个数尽量不要超过200
    当然本人没有用到IN200的时候;

    or 和union 这个我还没有特别的理解透彻,就不写了,以免误导大家,并且丢人现眼

12. %的模糊 使用
    这个地方要明白一个名词就是 负向查询
    例如:not; !=; <>; 等等 not in 类似这种

    尽量不要%1% 这样会影响B+树
    也会导致索引失效,导致全盘扫描

13. count(*) 慎用!!!

14. 这个地方是我觉得我印象 最深的地方
    关于分页的问题;
    传统 的limit分页,当大数据了量的时候处理办法和解决思路
    limit 100000,10 越大越慢;
    推荐写法:
    select a from table where id>= 100000 limit 11;
    第二种方式:
    先查询一次,然后外边再包一层,在limit
    第三种方式:
    join using ID
    还有一个:但是我没看明白;我就不写了

15. union all 和union的用法:
    union有去重开销;