SQL 优化

    查询语句是我们在开发中经常使用到的，可以说一个好的查询语句直接影响到网站的运行速度，这一点也不夸张。在今天，我更清楚的了解这个事实。

    一个简单的实例，足以说明这一切。

1) A表有500，000条，B表有1，000条数据，

2) A、B表都有FirstName，LastName两个字段，但其中这两个并不是完全匹配的，例如B表的FirstName有‘J.’的形式，认为是名字简写形式，会匹配A表以J开头的FirstName(James)

3) 要求找出B表匹配A表名字的数据。

 

分析：

1) A表有500，000条数据，说明A表是一个大数据表，对于数据超过300条的首先我们应该想到需要建立索引，对于A表这样的大数据表更是如此，并且A表和B表是通过firstname和lastname进行匹配的，因此我们这里可以通过建立firstname和lastname的索引。

2) B表的FirstName为J.的形式，因此我们这里要多考虑名字简写的形式，对于J.的形式，我们找出来然后再根据like来进行匹配。

 

根据分析，我们很容易写出：

select *
                from A,B where
                 A.LastName=B.LastName
                and ((INSTR(B.firstName,'.')>0 and
                A.FirstName like CONCAT(SUBSTRING_INDEX(B.firstName,'.',1),'%'))
                or (A.FirstName=B.FirstName));
语句没有问题，在Mysql 执行，结果耗时300多秒，好家伙，我还以为就死在那里了，再来分析这个语句，耗时这么长有可能就是因为在语句里面or的原因，根据这个推测，重新改写：

select *
                from A,B where
                 A.LastName=B.LastName
                and INSTR(B.firstName,'.')>0 and
                A.FirstName like CONCAT(SUBSTRING_INDEX(B.firstName,'.',1),'%')

union all

select *
                from A,B where
                 A.LastName=B.LastName
                and A.FirstName=B.FirstName;

再次查询，结果令人惊叹，耗时20几秒，没想到一个or居然会有这么大的差异。后来请教了下项目主管，才知道带有or,in,exists, not in, not exists 的sql语句都不是很好的设计。看来要将查询语句写好，尤其是这种大的数据表，效率表现的尤为突出，这是我们在平时开发中很容易遗忘的一点。

      值得一提的是，有时候对于这种有大数据表的，可以新建一个临时表专门用来存储大数据表中的经常会用到的数据或者和其他表关联的数据，这样，可以把和大数据表的连接转换为和这个临时表的连接，极大的减轻对服务器的压力。