共计 4906 个字符，预计需要花费 13 分钟才能阅读完成。
1. 在所有用于 where,order by 和 group by 的列上添加索引
索引除了能够确保唯一的标记一条记录，还能是 MySQL 服务器更快的从数据库中获取结果。索引在排序中的作用也非常大。
Mysql 的索引可能会占据额外的空间，并且会一定程度上降低插入，删除和更新的性能。但是，如果你的表格有超过 10 行数据，那么索引就能极大的降低查找的执行时间。
强烈建议使用“最坏情况的数据样本”来测试 MySql 查询，从而更清晰的了解查询在生产中的行为方式。
假设你正在一个超过 500 行的数据库表中执行如下的查询语句：
mysql>select customer_id, customer_name from customers where customer_id=’345546′
上述查询会迫使 Mysql 服务器执行一个全表扫描来获得所查找的数据。
型号，Mysql 提供了一个特别的 Explain 语句，用来分析你的查询语句的性能。当你将查询语句添加到该关键词后面时，MySql 会显示优化器对该语句的所有信息。
如果我们用 explain 语句分析一下上面的查询，会得到如下的分析结果：
mysql> explain select customer_id, customer_name from customers where customer_id=’140385′;
+—-+————-+———–+————+——+—————+——+———+——+——+———-+————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+———–+————+——+—————+——+———+——+——+———-+————-+
| 1 | SIMPLE | customers | NULL | ALL | NULL | NULL | NULL | NULL | 500 | 10.00 | Using where |
+—-+————-+———–+————+——+—————+——+———+——+——+———-+————-+
可以看到，优化器展示出了非常重要的信息，这些信息可以帮助我们微调数据库表。首先，MySql 会执行一个全表扫描，因为 key 列为 Null。其次，MySql 服务器已经明确表示它将要扫描 500 行的数据来完成这次查询。
为了优化上述查询，我们只需要在 customer_id 这一列上添加一个索引 m 即可：
mysql> Create index customer_id ON customers (customer_Id);
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
如果我们再次执行 explain 语句，会得到如下结果：
mysql> Explain select customer_id, customer_name from customers where customer_id=’140385′;
+—-+————-+———–+————+——+—————+————-+———+——-+——+———-+——-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+———–+————+——+—————+————-+———+——-+——+———-+——-+
| 1 | SIMPLE | customers | NULL | ref | customer_id | customer_id | 13 | const | 1 | 100.00 | NULL |
+—-+————-+———–+————+——+—————+————-+———+——-+——+———-+——-+
从上述的输出结果，显然 MySQL 服务器会使用索引 customer_id 来查询表格。可以看需要扫描的行数为 1。虽然我只是在一个行数为 500 的表格中执行这条查询语句，索引在检索一个更大的数据集的时候优化程度更加明显。
2. 用 Union 优化 Like 语句
有时候，你可能需要在查询中使用 or 操作符进行比较。当 or 关键字在 where 子句中使用频率过高的时候，它可能会使 MySQL 优化器错误的选择全表扫描来检索记录。union 子句可以是查询执行的更快，尤其是当其中一个查询有一个优化索引，而另一个查询也有一个优化索引的时候。
比如，在 first_name 和 last_name 上分别存在索引的情况下，执行如下查询语句：
mysql> select * from students where first_name like ‘Ade%’ or last_name like ‘Ade%’
上述查询和下面使用 union 合并两条充分利用查询语句的查询相比，速度慢了许多。
mysql> select * from students where first_name like ‘Ade%’ union all select * from students where last_name like ‘Ade%’
3. 避免使用带有前导通配符的表达式
当查询中存在前导通配符时，Mysql 无法使用索引。以上面的 student 表为例，如下的查询会导致 MySQL 执行全表扫描，及时 first_name 字段上加了索引。
mysql> select * from students where first_name like ‘%Ade’
使用 explain 分析得到如下结果：
mysql> explain select * from students where first_name like ‘%Ade’ ;
+—-+————-+———-+————+——+—————+——+———+——+——+———-+————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+———-+————+——+—————+——+———+——+——+———-+————-+
| 1 | SIMPLE | students | NULL | ALL | NULL | NULL | NULL | NULL | 500 | 11.11 | Using where |
+—-+————-+———-+————+——+—————+——+———+——+——+———-+————-+
如上所示，Mysql 将扫描全部 500 行数据，这将使得查询极其缓慢。
4. 充分利用 MySQL 的全文检索
如果你正面临着使用通配符查询数据，但是并不想降低数据库的性能，你应当考虑使用 MySQL 的全文检索（FTS），因为它比通配符查询快得多。除此以外，FTS 还能够返回质量更好的相关结果。
添加一个全文检索索引到 student 样表上的语句如下：
mysql> alter table students add fulltext(first_name, last_name)’;
mysql> select * from students where match(first_name, last_name) against (‘Ade’);
在上面的例子中，我们针对搜索关键字 Ade 指定了想要匹配的列 (first_name, last_name)。如果查询优化器如上语句的执行情况，将得到下面的结果：
mysql> explain Select * from students where match(first_name, last_name) AGAINST (‘Ade’);
+—-+————-+———-+————+———-+—————+————+———+——-+——+———-+——————————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+———-+————+———-+—————+————+———+——-+——+———-+——————————-+
| 1 | SIMPLE | students | NULL | fulltext | first_name | first_name | 0 | const | 1 | 100.00 | Using where; Ft_hints: sorted |
+—-+————-+———-+————+———-+—————+————+———+——-+——+———-+——————————-+
5. 优化数据库架构
规范化
首先，规范化所有数据库表，即使可能会有些损失。比如，如果你需要创建两张表分别用来记录 customers 和 orders 数据，你应当在 order 表上用顾客 id 引用顾客，而不是反过来。下图显示了没有任何数据冗余而设计的数据库架构。
除此以外，对相似的值使用同一种数据类型类存储。
使用最佳数据类型
MySQL 支持各种数据类型，包括 integer，float，double，date，datetime，varchar，text 等。当设计数据库表时，应当尽可能使用能够满足特性的最短的数据类型。
比如，如果你在设计一个系统用户表，而该用户数量不会超过 100 个人，你就应该对 user_ud 使用 ’TINYINT’ 类型，该类型的取值范围为 -128 至 128。如果一个字段需要存储 date 型值，使用 datetime 类型比较好，因为在查询的时候无需进行复杂的类型转换。
当值全为数字类型时，使用 Integer。在进行计算时，Integer 类型的值比文本类型的值速度更快。
避免 NULL
NULL 指该列没有任何值。你应当尽可能的避免这类型的值因为他们会损害数据库结果。比如你需要获得数据库中所有订单金额的和，但是某个订单记录中金额为 null，如果不注意空指针，很有可能导致计算结果出现异常。在某些情况下，你可能需要为列定义一个默认值。
