MySQL数据库优化方式总结

数据库学习笔记记录归纳

一、选取最适用的字段属性

1、字段宽度尽量小

MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

2、字段尽量设置为非NULL

另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。
避免使用 NULL 的目的，是便于代码的可读性和可维护性。同时也便于避免下文即将出现的一些稀奇古怪的错误。

2、使用 concat 函数拼接时，首先要对各个字段进行非 NULL 判断，否则只要任何一个字段为空都会造成拼接的结果为 NULL。
3、当用count函数进行统计时，NULL 列不会计入统计。
.count()不计算null，也就是count(col2)，所得的计数，是不包括有null值的行，这跟count()就有区别了，对于不熟悉的人可能会混淆，但我认为这些差别应该要知道，要统计表总行数，直接count()即可，也是最有效率的方法了，即使是慢也是全表扫描的锅。

在项目中优化mysql的时候字段尽量不要用NULL 值，使用-1或者其他特殊标识来替代，原因如下：

为NULL的列会使用更多的存储空间，在Mysql中也需要特殊处理
对Mysql来说更难优化，因为可为NULL的列会使索引统计和值比较都更复杂。
当可为NULL的列被索引时，每个索引记录需要一个额外的字节，在MyISAM里甚至还可能导致固定大小的索引（例如只有一个整数列的索引）变成可变大小的索引。
特别是：如果计划在列上建索引，列尽量设计成可not null

where子句中使用对null的判断，如果判断的列设置了索引，那是可以使用到索引的（mysql对这种情况会自动优化如果用索引不如全表扫描效率高那么会全文）。但是，只能使用针对一个字段的关于null的判断，如果同时在两个字段对null进行判断，还是会走全表扫描

3、分类数据设置为ENUM类型

对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

4、尽量使用数字型字段

若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了

5、尽可能的使用 varchar/nvarchar 代替 char/nchar

因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些

二、使用连接（JOIN）来代替子查询(Sub-Queries)

使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN）…替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：

SELECT*FROM customer_info
WHERE customer_id  NOT IN (SELECT customer_id FROM sales_info)

如果使用连接（JOIN）…来完成这个查询工作，速度将会快很多。尤其是当sales_info表中对CustomerID建有索引的话，性能将会更好，查询如下：

SELECT*FROM customer_info
LEFT JOIN sales_info ON customer_info.customer_id=sales_info.customer_id
WHERE sales_info.customer_id IS NULL

连接（JOIN）之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

三、使用联合(UNION)来代替手动创建的临时表

UNION 操作符用于合并两个或多个 SELECT 语句的结果集。
注意，UNION 内部的每个 SELECT 语句必须拥有相同数量的列。列也必须拥有相似的数据类型。同时，每个 SELECT 语句中的列的顺序必须相同。

MySQL从4.0的版本开始支持UNION查询，它可以把需要使用临时表的两条或更多的SELECT查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用UNION来创建查询的时候，我们只需要用UNION作为关键字把多个select语句连接起来就可以了。

四、使用事务（Transaction）保证数据一致性与提高速度

尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。
要避免这种情况，就应该使用事务，它的作用是：

要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。
事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。
写成事务的形式，不需要多次连接数据库，能够提高性能，增快增删查改的速度。

BEGIN; //或start transaction
INSERT INTO salesinfo SET CustomerID=14;//语句1
UPDATE inventory SET Quantity=11 WHERE item='book';//语句2
COMMIT;
//若失败如
//if(update失败) {rollback}

常见的例子就是银行转账，A账户给B账户转账一个亿(T1)。在这种交易的过程中，有几个问题值得思考：
如何同时保证上述交易中

A账户总金额减少一个亿，B账户总金额增加一个亿？ A
A账户如果同时在和C账户交易(T2)，如何让这两笔交易互不影响？ I
如果交易完成时数据库突然崩溃，如何保证交易数据成功保存在数据库中？ D
如何在支持大量交易的同时，保证数据的合法性(没有钱凭空产生或消失) ？ C
要保证交易正常可靠地进行，数据库就得解决上面的四个问题，这也就是事务诞生的背景，它能解决上面的四个问题，对应地，它拥有四大特性：也即ACID 注意ACID是事务的性质而非数据库的性质

原子性（Atomicity）: 事务要么全部完成，要么全部不发生。如果事务崩溃，状态回到事务之前（事务回滚）。它们不可分割。如A账户少了一个亿，B必须多一个亿。
隔离性（Isolation）: 事务之间是独立的。比如我们打开一个word文档，再打开相同的文档的时候，应该设置不可打开，防止冲突。具体可通过枷锁来解决。
持久性（Durability）: 一旦事务提交，不管发生什么（如数据库崩溃或者出错），数据仍然能保存在数据库中。当数据库崩溃或者服务器断点时，重启动SQL SERVER，SQLSERVER首先会检查日志顺序号，将本应对数据库做更改而未做的部分持久化到数据库，从而保证了持久性。
一致性（Consistency）: 一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性约束包括但不限于：实体完整性（如行的主键存在且唯一）、列完整性（如字段的类型、大小、长度要符合要求）、外键约束、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。依赖原子性和隔离性。

数据库通过事务日志来达到这个目标

如果每次更新都写盘，由于数据是随机的，会造成大量的随机IO，性能会非常差
如果每次更新不马上写盘，那一旦数据库崩溃，数据就会丢失

折中的办法就是：

将数据的变更以事务日志的方式，按照时间先后追加到日志缓冲区，由特定算法写入事务日志，这是顺序IO，性能较好
通过数据管理器解析事务日志，由特定的算法择机进行写盘

事务还有隔离级别的概念可对不同的业务加不同级别的隔离锁以提高性能

五、锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE SELECT Quantity FRO Minventory WHERE Item='book';
//一些计算写在这里
UPDATE inventory SET Quantity=11 WHERE Item='book';
UNLOCK TABLES

这里，我们用一个select语句取出初始数据，通过一些计算，用update语句将新值更新到表中。包含有WRITE关键字的LOCK TABLE语句可以保证在UNLOCK TABLES命令被执行之前，不会有其它的访问来对inventory进行插入、更新或者删除的操作。

六、使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。

例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。


CREATE TABLE customerinfo( CustomerID INT NOT NULL,PRIMARYKEY(CustomerID)) TYPE=INNODB;
CREATE TABLE salesinfo( SalesID INT NOT NULL,CustomerID INT NOT NULL,PRIMARYKEY(CustomerID,SalesID),
FOREIGN KEY(CustomerID)REFERENCES customerinfo(CustomerID)ON DELETE CASCADE)TYPE=INNODB;

注意例子中的参数“ON DELETE CASCADE”。该参数保证当customerinfo表中的一条客户记录被删除的时候，salesinfo表中所有与该客户相关的记录也会被自动删除。
如果要在MySQL中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表InnoDB类型。该类型不是MySQL表的默认类型。定义的方法是在CREATETABLE语句中加上TYPE=INNODB。如例中所示。

七、使用索引

索引可以用字典中安装首字母A、B、C……编排顺序，来帮助理解，比如，当我们给数据加上索引后，就可以快速的根据“首字母”来找到数据，而不用每条都去检索了。
尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候，使用索引可使数据库性能提高更为明显。

那该对哪些字段建立索引呢？

一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDERBY排序的字段上。
索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率

注意以下情况：

尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况
在建有索引的字段上尽量不要算数运算或使用函进行操作。例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。

 select * from users where YEAR(adddate)<2007;
//将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成
select * from users where adddate<‘2007-01-01';

再比如：

SELECT*FROM books  WHERE name＞="MySQL" and name＜"MySQM"

再如：

select id from t where num/2 = 100
//应改为:
select id from t where num = 100*2

应该注意避免在查询中让MySQL进行自动类型转换（如比较int类型与char类型），因为转换过程也会使索引变得不起作用。
使用短索引，对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from where num is null
最好不要给数据库留NULL，可以的话尽量使用 NOT NULL填充数据库（如0），特别是那些需要判断的字段。不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了，不管是否插入值（NULL也包含在内），都是占用 100个字符的空间的，但如果是varchar这样的变长字段， null 不占用空间。
少用IN、NOT IN、<>、!=操作 这些操作都不会使用索引将进行全表扫描。
1、对于连续的数值，尽量用 between代替in，或使用exits
如select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
再如:
select id from t where num in(1,2,3)
用下面的语句替换
select id from t where num between 1 and 3
2、NOT IN可以NOT EXISTS代替
3、id<>3则可使用id>3 or id<3来代替
应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or Name = ‘admin’ 可以这样查询：

select id from t where num = 10 union all select id from t where Name
= ‘admin’

使用 mysql 5.6,在测试中 sql 语句最前面都加有 explain 关键字，explain SELECT * FROM t_supplier_hr WHERE id > 9865 or supplierid > 30 or tttd =‘7sd5’ 在这个语句中 3个字段都是有索引的，查询下来是没有走索引的，但把sql 改为 explain SELECT * FROM t_supplier_hr WHERE id > 9865 or supplierid > 30 它就走了索引，具体是什么原因走了索引这确实没有找到原因，只能说相对较短的 or 语句是走索引的，多个就不一定了，在使用前最好还是加上 explain 来试试到底走不走索引。而对于 in 进过多次测试是走索引的。

索引的详细操作以及单列、组合索引的介绍和区别可看以下链接（程序猿面试常考）
https://blog.csdn.net/S_ZaiJiangHu/article/details/114420976

其中注意复合索引：

比如我们创建了(area, age,salary)的复合索引，那么其实相当于创建了(area,age,salary)(area,age)、(area)三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。
复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL！！！！！！！!!！！!!！!!！

八、其他优化的查询语句

绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。

下面是应该注意的几个方面。

1，最好是在相同类型的字段间进行比较操作

在MySQL3.23版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较（如大于小于）。

2、少用LIKE关键字和通配符

在搜索字符型字段时，我们有时会使用LIKE关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。

例如下面的查询将会比较表中的每一条记录。

SELECT*FROM books WHERE name like "MySQL%"

但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：

SELECT*FROM books WHERE name＞="MySQL" and name＜"MySQM"

如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

3、强制查询使用索引

如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num = @num
//可以改为强制查询使用索引：
select id from t with(index(索引名)) where num = @num

4、大数据先分页再join

对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。

5、select只选择需要的字段

要使用 select * from xxx ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

6、

在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

7、游标

尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

8 、

在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

9、拆分大的 DELETE 或INSERT 语句，批量提交SQL语句

如果你需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。
　　Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器资源的事情，尤其是内存。
　　如果你把你的表锁上一段时间，比如30秒钟，那么对于一个有很高访问量的站点来说，这30秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你的WEB服务崩溃，还可能会让你的整台服务器马上挂了。
　　所以，如果你有一个大的处理，你一定把其拆分，使用 LIMIT oracle(rownum),sqlserver(top)条件是一个好的方法。下面是一个mysql示例：

while(1){//每次只做1000条mysql_query(“delete from logs where log_date <= ’2012-11-01’ limit 1000”);if(mysql_affected_rows() == 0){//删除完成，退出！break；}//每次暂停一段时间，释放表让其他进程/线程访问。
usleep(50000)}

九、数据库设置优化（运维）

可参考：https://blog.csdn.net/S_ZaiJiangHu/article/details/114500679

主键的设置

逻辑主键：采用与业务无关的唯一性的字段做主键，或称之为“伪主键”
业务主键：把具有实际含义的字段作为主键

逻辑主键的好处：1，因为具有业务含义的列都有修改的可能性（比如员工号，产品编号等等），
如果有其他表引用该字段作为外键，要引起级联修改，
消除主键（业务字段）修改引起的一致性问题
2，业务主键可能由多个列组成（比如上班打卡记录，由员工号+日期组成），
这样的话，如果有其他表引用该表的主键做外键，需要存储多个字段，造成存储空间的扩大（多个主键必然引起·· 且会引起索引的文件大小）
消除业务主键由多个字段组成引起的冗余存储
3，如果是复合主键的话，会造成一些业务无法实现，
比如有多个字段作为主键，在应用中只有这些字段全部输入后才能呢个保存，
现实中有些功能是“保存草稿”状态的，也就是说必填字段可以在没有填写的情况下实现保存，
如果不采用逻辑主键的话，此功能就无法实现
4，应用程序中不方便，比如像查询一个对象的明细信息，如果采用业务主键，可能需要传递多个参数才能确定一条数据（更方便地实现业务功能）

业务主键的好处：1，不需要逻辑键的冗余存储，
2，可以直接根据业务主键确认一条数据

注意！

使用查询的时候，需要保证查询语句的类型和mysql中定义的类型，以及连表的时候的类型一致！特别是当你使用弱类型语言和整型的时候！比如用户的user_id 设置为字符串因为你要搞000145这种号码，这时候就可能把000122这种当初字符串而12345这种当成整型

当MySQL的Where值类型和数据库定义的字段类型不一致时会发生:

建立的索引实际没有被使用上，导致查询效率低下。
由于数据库对一些值的默认转化，导致查询的结果偏离实际的期望。

字段类型不一样，在进行比较时，用不上index是符合运算的列使用不了index。

php的bind_param() 函数可以部分解决这个问题，告诉mysql我要传入的类型

字段名不要和sql保留关键字一样比如limit

优化实例