摘要：
我们先不谈OR对数据库性能的致命性。将来，如果在线项目是一个包含大量数据的表，则不能使用OR进行查询。今天，当工作时，有SQL事务，并且一个非常重要的表被锁定，整个系统开始变得很混乱。之后，一个查询持续16秒，我在5秒内检查了JK_ Customer表中的数据：有300多万条数据。主键必须有索引是很好的。如果您想快速查询，情况不会改变。很明显，手术室损坏了我的索引。
关于 数据库 or 的用法，就不说了 讲讲OR对数据库性能有多大的杀伤力，以后线上的项目如果是数据量很大的表，一定不要用OR来查询
今天在工作的时候，同事遇到了SQL优化的问题，有SQL事务，锁了一张很主要的表，整个系统都开始拉胯，一卡一卡的。。
让我帮忙看看，之后一个长达16秒的查询，优化到不到一秒
SQL： 
用时：五秒 
我检查一下 JK_Customer 这张表的数据， 有三百多万条数据 还好
主键是肯定有索引的 想查询快的话，加索引呗
加索引后： 情况没有变化 
这情况就很明显了，OR这个玩意儿 破坏了我的索引：我来试试分开查询
瞬间完成，OK 。。
事实证明了，OR破坏了的我的索引 导致查询变慢了
那么我们就不要怕麻烦 用UNION ALL来代替我们的OR
总结： or会破坏索引
如果A表很大的情况下，应改成：
