mysql索引

1. b+树
   平衡二叉树，叶子节点排序。
   节点结构是key+地址+指向下个节点的指针。
   因为是排序，连续的，所以可以范围查找。
2. hash
   hash索引存的是hash值，所以会不连续。
   因为不连续，所以不能范围查询，也无法外排序。
   当出现hash冲突的时候，存储引擎必须遍历整个链表中的所有行指针，逐行比较；所以不适合重复多的列。
   相关链接：https://blog.csdn.net/z_ryan/article/details/82322418

---

mysql5.7之前，仅innodb支持行锁、事务。
如果不在乎可扩展能力和并发能力，也不需要事务支持，也不在乎崩溃后的安全恢复问题的话，选择MyISAM也是一个不错的选择。

innodb中：在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

分库分表之后,id 主键如何处理？
因为要是分成多个表之后，每个表都是从 1 开始累加，这样是不对的，我们需要一个全局唯一的 id 来支持。

生成全局 id 有下面这几种方式：

• UUID：不适合作为主键，因为太长了，并且无序不可读，查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。
• 数据库自增 id : 两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。这种方式生成的 id 有序，但是需要独立部署数据库实例，成本高，还会有性能瓶颈。
• 利用 redis 生成 id : 性能比较好，灵活方便，不依赖于数据库。但是，引入了新的组件造成系统更加复杂，可用性降低，编码更加复杂，增加了系统成本。
• Twitter的snowflake算法 ：Github 地址：https://github.com/twitter-archive/snowflake。
• 美团的Leaf分布式ID生成系统 ：Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。感觉还不错。美团技术团队的一篇文章：https://tech.meituan.com/2017/04/21/mt-leaf.html 。
  …

尽可能把所有列定义为 NOT NULL
原因：索引 NULL 列需要额外的空间来保存，所以要占用更多的空间；进行比较和计算时要对 NULL 值做特别的处理

避免使用子查询，可以把子查询优化为 join 操作
原因：　子查询结果集不能使用索引

拆分复杂的大 SQL 为多个小 SQL
•大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL
•MySQL 中，一个 SQL 只能使用一个 CPU 进行计算
•SQL 拆分后可以通过并行执行来提高处理效率

对于大表使用 pt-online-schema-change 修改表结构
•避免大表修改产生的主从延迟
•避免在对表字段进行修改时进行锁表

对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是生产环境，是不能容忍的。

pt-online-schema-change 它会首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。把原表中新增的数据也复制到新表中，在行所有数据复制完成之后，把新表命名成原表，并把原来的表删除掉。把原来一个 DDL 操作，分解成多个小的批次进行。