数据库优化

数据库优化很容易说一些大而无用的空话，每个人都会说。所以应该要具体，才能让人信服。

1. 表字段的优化

1.1 项目中的数据表全部为单表，没有外键。早就是这样的了。
1.2 因设备名称会经常模糊查询，所以再建立一个search_name列来存储设备名称的unicode值，提高查询效率。
1.3 定长与变长字段分离，常用和不常用字段分离。定长的字段放在一起，常用的字段方向在一起。
如id的int，char ，注意还有timestamp都是定长的，数据在查询时定长会很快。
1.4 添加冗余字段。如当时我们将组织名称和某些情况下的设备名称会做一个冗余字段，这样就减少了关联查询。
1.5 字段类型的优先选择：int > time（不包含时区的） ,date > char > varchar > text ,json(postgres特有的）

2. 索引相关

2.1 索引的左前缀原则。
注意分组排序等也可以利用到索引 where a=1 and b=4 order by c。根据项目实际情况，哪些字段查询的多，就做成联合索引。
联合索引本质：
当创建(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)联合索引以及(a,b,c)联合索引
想要索引生效的话,只能使用 a和a,b和a,b,c三种组合；当然，我们上面测试过，a,c组合也可以，但实际上只用到了a的索引，c并没有用到！

2.2 聚簇索引和非聚簇索引

• 聚簇索引
  聚簇索引指 索引即存储索引值又在叶子结点存储实际行的数据，因此不必再根据地址去磁盘查。对于次级索引会存着主键的id，指向对主键的引用，主键的索引那里存着实际的数据。如innodb 。所以一张表只能有唯一的聚簇索引，但是可以有多个次级索引
  如果主键不规律，在插入时需要频繁的变动叶子数结构，造成不平衡的页分裂问题。因此对于innodb的主键要非常小心，最好是该主键有一些聚集性和自增性，否则插入和删除可能性能非常低下，无规律的数据库会产生页的分裂影响速度
• 非聚簇索引
  myisam中，主索引和次索引都指向数据磁盘所在位置。

2.3 覆盖索引
如果索引包含所有满足查询需要的数据，称为覆盖索引(Covering Index)，也就是平时所说的不需要回表操作。
通常开发人员会根据查询的where条件来创建合适的索引，但是优秀的索引设计应该考虑到整个查询。其实mysql可以使用索引来直接获取列的数据。如果索引的叶子节点包含了要查询的数据，那么就不用回表查询了，也就是说这种索引包含（亦称覆盖）所有需要查询的字段的值，我们称这种索引为覆盖索引
覆盖索引就是从索引中直接获取查询结果，要使用覆盖索引需要注意select查询列中包含在索引列中；where条件包含索引列或者复合索引的前导列；查询结果的字段长度尽可能少。
2.4 理想索引

• 查询频繁。这个肯定是在查询频繁的字段上建立索引
• 区分度高。肯定不能在男女这样的字段建立索引
• 长度较短。不然更新速度很慢，占用内存多
• 要覆盖常查询的列

2.5 技巧
对于存储http：//www.baidu.com这样地址的字段，前面的都是http：//开头，可以采用倒序的方式建立索引。也可以采用伪哈希的方式，将内容哈希后建立索引，查询时将要查询的值先哈希再去查。

2.6 重复索引和冗余索引
重复索引没有任何好处，浪费。冗余索引：比如相同两列建立联合索引，但是顺序不同。

2.7 索引碎片和维护。
磁盘容易导致内存碎片化，可以运行一些数据库的命令修复。

2.8 type
all < index < range < ref < const