花时间重修了一下以前的数据库原理,需要给自己的充充电。

数据库优化的部分:

  • 一、数据库的设计
  • 二、sql语句的优化

一、数据库(表)的设计

1. 范式:

目前基本都符合3NF,我觉得3NF目前来讲是足够的。

  • 1NF:关系型数据库的原子性
  • 2NF:唯一性(主键)
  • 3NF:通过关联的关系进行派生,通常通过外键的关系。

有些时候是需要进行范式降级的,高的范式不一定就是没有任何的问题,有时候冗余还是必要的。

当初《数据库系统原理》没有认真学的后果是现在必须去补一补了。。。

二、sql语句优化

其实最关键的部分还是SQL语句的优化。

sql语句优化的一般步骤是:

  • 通过 show status 了解各种sql的执行效率
  • 定位执行效率较低的sql语句,尤其是select,是万恶之源
  • 通过explain分析低效率sql语句的执行情况
  • 确定问题并采取相应的优化措施

1. show status:

show status 能够显示mysql(虽然我现在更多的使用mariaDB,不过换汤不换药)当前状态,主要关心的com开头的指令;

show status like 'Com%' 
# 等同于 show session status like 'Com%' //显示当前控制台的情况

show global status like 'Com%' // 显示从数据库启动到查询时查询的次数 

其他有用的几个参数:

  • connenctions; 视图链接mysql服务器的次数
  • uptime; 服务器工作的时间
  • slow_queries; 慢查询的次数(默认10秒)
show status like "connecitons";

show status like "slow_queries";

show status like 'uptime';

show variables like 'long_query_time';

2.定位慢查询

利用mysql日志查看慢查询语句

3.索引

索引这个就不用说了,如果连索引没有,不用谈数据库优化了。

  • 索引的代价:

    • 占用磁盘空间(这个可以忽略吧)
    • 牺牲了增删改的性能,因此索引不能盲目的添加

三篇文章可以参考:

4. explain

可以利用explain 进行sql分析:

下面的sql语句,如果在uid上没有建立索引,那么扫描的类型肯定是全表扫描的。

explain select * from user where uid = 1;

explain select * from user where uid = 2\G;

# 可以比较一下结果

在有索引的表上进行的查询:

QQ截图20170412170837.jpg

没有索引的表上进行的查询:

QQ截图20170412171015.jpg

当然,如果是like的匹配还是建议进行全文索引的