数据库查询优化

索引设计优化：

• 为了提升查询速度提供的一种数据结构, 相似书的目录, 方便快速查询出数据, 而不是从头至尾的依次比对

• 优势

  • 增长查询速度

  • 索引不只能够提升精确查询的速度, 还能够提升排序和分组的效率

• 缺点

  • 增长数据库的存储空间

  • 减慢增删改速度(索引须要随之改变)

• 建立索引

create table t_user(
  id int not null,  
  mobile char(10) not null,
  key (mobile)  # 设置索引
) 

alter table t_user add nickname varchar(20);
alter table t_user add key (nickname);

查看索引： show keys from t_user;

查看查询是否使用是索引：explain select * from t_user where nickname = 'zs';

 

二，索引分类：

• 主键索引

  • 建立主键后自动生成

• 惟一索引

  • 设置惟一约束后自动生成

• 外键索引

  • 设置外键约束后自动生成

• 普通索引 index

  • 不要用可空列做为索引, 易出错

  • 适合的字段

    • 常常出如今Where子句中的字段，特别是大表的字段，应该创建索引；

    • 常常与其余表进行链接的表，在链接字段上应该创建索引；

    • 索引应该建在选择性高(取值范围广)的字段上；

    • 频繁进行数据操做的表，不要创建太多的索引；

  • 场景

    • 自定义的外键字段(逻辑外键)

    • 高选择性, 查询频繁的接口

mysql的索引存储结构为B+tree结构，平衡二叉树

聚簇索引:

• 叶子节点上存放的是数据行

• InnoDB引擎的主键索引使用这种存储方式

• 二级/辅助索引(全部非主键索引)的叶子节点上存放的是主键值, 因此二级索引须要进行二次查询

 

 

 非聚簇索引: 在叶子节点上存储的是数据行的物理地址, 数据行和索引存储在不一样的结构中

 

 

 

多列/联合索引

• 联合索引必须符合最左原则, 不然无效

  • where mobile /where mobile and type会使用索引

  • where type 不会使用索引

create table t_user(
  id int not null,  # 非空约束
  mobile char(10) not null,
  type tinyint default 0,
  key k_mobile_type (mobile, type)  # 设置联合索引
)    

key testindex (type, 姓, 名) 
select 姓, 名 from t_user where type = 1;

覆盖索引

• 若是一个索引包含(或者说覆盖)全部须要查询的字段的值, 称为"覆盖索引"

• 若是查询触发了覆盖索引, 将直接从索引中提取出数据, 而不会再去查询数据行

• 合理利用覆盖索引机制, 极大的提升性能

• 应用场景

  • 分页优化

  • 优化二次查询

  • 提升or运算的查询速度

create table t_user(
  id int auto_increment primary key,  
  name varchar(20) not null,
  age int default 0,
  key test_index (name, age)  # 设置联合索引
)    

select age from t_user where name = 'zs';  # 使用覆盖索引

5. 主键设计

• InnoDB的主键为何选择自增

  • 数据和主键索引是绑定在一块儿的, 主键自增则会让数据顺序添加到B+Tree中, 不会因移动数据而影响插入速度

• 复合/联合主键

  • 将多个业务键联合定义为主键

  • 优势

    • 节省空间

  • 缺点

    • 不是自增, 性能差

    • 没法做为其余表的外键

  • 尽可能不要用

   

6. 三范式和反范式设计 (重点)

• 规则

  • 第一范式: 字段具备原子性, 不可拆分

  • 第二范式: 依赖于所有主键, 而非部分主键

    • 主要针对复合主键,通常都会遵照

    • 好比某人的成绩 由班级+姓名决定, 成绩彻底依赖于班级+姓名, 可是班主任姓名只依赖于班级, 不依赖学生姓名, 则不能在该表中

  • 第三范式: 只依赖于主键, 非主键字段互不依赖

• 目的

  • 减小冗余字段/重复的数据

---

• 回复数/评论数/点赞数 均可以经过聚合查询来获取 select count(*) from t_comment group by news_id

• 若是单独定义字段来记录, 该字段就称为冗余字段

• 这种设计称为 反范式设计

  • 经过加入冗余字段/重复数据 来提升数据库的查询速度

  • 减小关联查询

  • 用空间换取时间

• 范式是武功招式, 如何运用全看本身

 

7. 数据库引擎

• 实现数据存储的不一样解决方案

• InnoDB mysql5.5开始 默认

  • 支持事务(回滚/提交/ACID特性/多版本并发控制等)

    • 数据恢复可以使用事务日志(undo/redo log), 恢复速度快

  • 支持行级锁&表级锁

    • 并发访问时效率高

  • 支持外键约束

  • 插入/更新/主键查询快

  • 须要内存和硬盘多

  • 常规推荐使用

• MyISAM

  • 不支持事务

  • 只支持表级锁

  • 不支持外键约束

  • 批量插入/查询/count( )速度快

  • 简单, 适合小型项目/以批量插入和查询为主的系统(内部管理系统)

• 系统公告表选择了MyISAM

  • 由于基本不会修改, 不存在大量并发写操做, 也就不须要行级锁提供并发能力

  • 和其余表没有关联, 不须要事务提供原子性等支持

• 查询多, MyISAM会更快

   

8. 字符集

• 字符集问题

  • utf-8若是保存数据中包含表情符号会崩溃

  • utf-8编码最大字符长度为3字节, 而unicode中大编码实现的表情符号(emoji)为4字节

  • 编码方式须要设置为utf8mb4

• sql注释 COMMENT xxx

• show create table xx; / show full columns from test; 能够显示出注释