整理这篇文档也算是有感而发，起因就是染布生产进度大约5W多条数据，每次导出为excel表格的时候服务器上的cpu压力爆满，而项目的架构又从源头上限制了从硬件层面上优化，故本篇文章仅仅从sql语句的写法上和数据表的设计上对mysql的性能进行优化。

结论1：框架自带的模型查询比原生的sql要慢很多（成立）

            这里我们通过microtime()函数来获取执行sql查询所需要的时间 

laravel自带的sql查询 查询时间为5.29秒 原生sql语句 查询时间为0.29秒

    通过上图的两条sql运行时间，我们可以明显的看出框架自带的查询耗时大约5.29秒，而原生的sql只需要0.29秒.

结论2：最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库（待定）

        测试的数据库中 actual_scheduling_bacth的数据类型是varchar（255）

        $sql ="select * from `dye_production_schedules` where `actual_scheduling_bacth` is null";

        sql执行时间为0.59701204299927秒

        $sql ="select * from `dye_production_schedules` where `actual_scheduling_bacth` = 0";

        sql执行时间为0.62539100646973秒

        对于varchar 字段来说 null 是不占用任何空间的，查询起来反而还要快，因此像评论或者描述这些我们可以用null，其他的并不推荐，但是对于char（100）来说，哪怕是null也会占用100字节空间

3.应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描（成立）

        对于上面两条sql来说

        id != 6055  的sql执行时间为0.54877090454102秒

        id>6055 or id<6055 的sql执行时间为0.0015900135040283秒

4.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描（待定）

        $sql1="select id from `dye_production_schedules` where id >  1666 and order_detail_id = 6891";

        $sql2 ="select id from `dye_production_schedules` where id > 1666  union all select id from `dye_production_schedules` where order_detail_id = 6891";

        好吧$sql2反而还慢

5.in 和 not in 也要慎用，否则会导致全表扫描（待定）

    对于连续的数值，能用 between 就不要用 in 了：

        $sql1 ="select id from `dye_production_schedules` where product_id in (2401,2402.2403)";

        $sql2 ="select id from `dye_production_schedules` where product_id between 2400 and 2404";

    好吧这两条执行速度极为相近  sql执行时间为0.00124192237854秒

6.%abc%的查询也将导致全表扫描

    select id from t where name like‘%abc%’

7. sql子句中尽量不要进行函数操作，表达式操作

.8Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。

8.尽可能的使用 varchar 代替 char ，

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

9.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

10尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

        批量处理数据（可分批向缓存中存贮）避免数组盛放过多的数据 给服务器造成巨大的压力