深入了解数据库：掌握explain使用方法 (数据库explain的用法)
在如今的互联网时代，数据的管理和使用相当重要，尤其是在企业或者组织中，数据更是至关重要的组成部分。为了更好地管理和利用数据，数据库诞生了。数据库通常包括数据、数据定义、数据操纵和数据控制等几个方面。而要想提高数据库的效率和性能，就需要掌握expln的使用方法。
什么是expln？
在MySQL中，expln是一种可以分析SQL查询语句的工具，可以根据查询语句来生成一个执行计划，包括了查询优化器的选择，数据的访问方式等等，从而帮助我们找到SQL语句中出现性能问题的问题所在，从而对其进行优化。
expln的使用方法
expln的语法十分简单，就是在查询语句的前面添加一个expln关键词即可。例如下面是一个查询语句：
SELECT * FROM user WHERE name = ‘abc’;
那么使用expln就是将其改写为：
EXPLN SELECT * FROM user WHERE name = ‘abc’;
执行这个语句之后，我们就可以得到这个查询语句的执行计划。
执行计划中包含了许多重要的字段，下面我们来介绍一下：
id：指定了查询中的每个表的唯一标识符，可以用来确认表的访问顺序。
select_type：查询的类型，例如简单查询、子查询或者联合查询等等。
table：表名，该查询的数据来自哪个表。
partitions：用于表示查询中的表被分区的情况。
type：访问表的方式，例如全表扫描、索引扫描等等。
possible_keys：表示用于此查询的可用参数
key：表示锁定来自相应表的记录的索引（如果有）
rows：表示MySQL执行查询以返回所需结果所需检查的行数的估计值。
Extra：包含一些关于查询的各种信息，例如使用了哪个索引、是否使用了临时表等等。
根据上面的信息，我们可以发现，能够从执行计划中获得很多有用的信息。例如，如果查询结果中表的访问方式是全表扫描，那么很可能是因为该表没有被正确地索引。因此，我们需要针对索引进行优化，以便更快地访问表。
除此之外，在查询语句执行过程中，expln还可以为我们分析不同的执行方案，以及各种执行方案下的IO和CPU等消耗情况等等，从而更精细地分析性能瓶颈。
Expln可以提供查询语句执行计划的详细信息，从而让我们更好地了解查询语句的性能和优化方向。对于需要对数据库性能进行优化的工程师来说，掌握expln的使用方法是一个不可或缺的技能。但是需要注意的是，不要过度使用expln，因为执行过程会影响数据库的性能。
相关问题拓展阅读：
数据库索引的操作案例
最普通的情况，是为出现在where子句的字段建一个索引。为方便讲述，先建立一个如下的含租表。
CREATE TABLE mytable(
idserial primary key,
category_id int not null default0,
user_id int not null default0,
adddate int not null default0
);
如果在查询时常用类似以下的语句：
SELECT * FROM mytable WHERE category_id=1;
最直接的应对之道，是为category_id建立一个简单的索引：
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一个选择条件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
之一反应可能是，再给user_id建立一个索引。不好，这不是一个更佳的方法。可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名时的习惯了吗？使用表名_字段1名_字段2名的方式。很快就会知道为什么这样做了。
现在已经为适当的字段建立了索引，不过，还是有点不放心吧，可能会问，数据库会真正用到这些索引吗？测试一下就OK，谈宏兆对于大多数的数据库来说，这是很容易的，只要使用EXPLAIN命令：
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactlyasI expected)
NOTICE:QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的数据，可以看到该数据库在查询的时候使用了一个索引（一个好开始），而且它使用的是创建的第二个索引。看到上面命名的好处了吧，马上知道它使用适当的索引了。
接着，来个稍微复杂一点的，如果有个ORDERBY 子句呢？不管你信不信，大多数的数据库在使用orderby的时候，都将会从索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很简单，就像为where子句中的字段建立一个索引一样，也为ORDER BY的子句中的字段建立一个索引：
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:mytable_categoryid_userid_adddate将会被截短为mytable_categoryid_userid_addda
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE:QUERY PLAN:
Sort(cost=2.03..2.03 rows=1 width=16)
->Index Scanusing mytable_categoryid_userid_addda
on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的输出，数据库多做了一个没有要求的排序，这下知道性能如何受损了吧，看来对于数据库的自身运作是有点过于乐观了，那么，给数据库多一点提绝码示吧。
为了跳过排序这一步，并不需要其它另外的索引，只要将查询语句稍微改一下。这里用的是postgres，将给该数据库一个额外的提示–在ORDER BY语句中，加入where语句中的字段。这只是一个技术上的处理，并不是必须的，因为实际上在另外两个字段上，并不会有任何的排序操作，不过如果加入，postgres将会知道哪些是它应该做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE:QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
现在使用料想的索引了，而且它还挺聪明，知道可以从索引后面开始读，从而避免了任何的排序。
以上说得细了一点，不过如果数据库非常巨大，并且每日的页面请求达上百万算，想会获益良多的。不过，如果要做更为复杂的查询呢，例如将多张表结合起来查询，特别是where限制字句中的字段是来自不止一个表格时，应该怎样处理呢？通常都尽量避免这种做法，因为这样数据库要将各个表中的东西都结合起来，然后再排除那些不合适的行，搞不好开销会很大。
如果不能避免，应该查看每张要结合起来的表，并且使用以上的策略来建立索引，然后再用EXPLAIN命令验证一下是否使用了料想中的索引。如果是的话，就OK。不是的话，可能要建立临时的表来将他们结合在一起，并且使用适当的索引。
要注意的是，建立太多的索引将会影响更新和插入的速度，因为它需要同样更新每个索引文件。对于一个经常需要更新和插入的表格，就没有必要为一个很少使用的where字句单独建立索引了，对于比较小的表，排序的开销不会很大，也没有必要建立另外的索引。
以上介绍的只是一些十分基本的东西，其实里面的学问也不少，单凭EXPLAIN是不能判定该方法是否就是更优化的，每个数据库都有自己的一些优化器，虽然可能还不太完善，但是它们都会在查询时对比过哪种方式较快，在某些情况下，建立索引的话也未必会快，例如索引放在一个不连续的存储空间时，这会增加读磁盘的负担，因此，哪个是更优，应该通过实际的使用环境来检验。
在刚开始的时候，如果表不大，没有必要作索引，意见是在需要的时候才作索引，也可用一些命令来优化表，例如MySQL可用OPTIMIZETABLE。
数据库explain的用法的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库explain的用法,深入了解数据库：掌握explain使用方法,数据库索引的操作案例的信息别忘了在本站进行查找喔。
