之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。
站在用户的角度思考问题，与客户深入沟通，找到周宁网站设计与周宁网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站设计制作、网站设计、企业官网、英文网站、手机端网站、网站推广、主机域名、网站空间、企业邮箱。业务覆盖周宁地区。
目前看来有几点优化空间，首先，这几个case部分，不需要这样强行变成bool值，数据库原样返回这些数据，前台显示的时候判断这一点。其次，多重join时，应该首先join排除能力最强的一个。
一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
关于mysql case when 的难题，怎么解决 else不能直接级联，只能级联case，应该这么写 1。
1、索引查询 建立索引后，合适的查询语句才能大发挥索引的优势。另外，由于查询优化器可以解析客户端的sql语句，会调整sql的查询语句的条件顺序去匹配合适的索引。
2、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
3、接着MySQL就会自动记录查询语句的proling信息。
4、\ 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。\ 我们增加了 hint，指导 MySQL 正确进行优化判断。但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。
5、select * from tablename；//此时查询的是所有的记录，用时可能比较多。select * from tablename limit 20，40；//这样就只会查询出需要的第20条到40条。
1、BTREE是常见的优化要面对的索引结构，都是基于BTREE的讨论。B-TREE 查询数据简单暴力的方式是遍历所有记录；如果数据不重复，就可以通过组织成一颗排序二叉树，通过二分查找算法来查询，大大提高查询性能。
2、mysql使用select * limit offset， rows分页在深度分页的情况下。性能急剧下降。limit用于数据的分页查询，当然也会用于数据的截取，下面是limit的用法： 模仿百度、谷歌方案（前端业务控制）类似于分段。
3、根据所描述的问题，可尝试在mms_profitcenter 的FOrderID ，FSuffix列上建立索引，再查询试试。
4、我们知道，MySQL 一直依赖对 count(*) 的执行很头疼。很早的时候，MyISAM 引擎自带计数器，可以秒回；不过 InnoDB 就需要实时计算，所以很头疼。
1、mysql的 io 以page为单位，因此不必要的数据（大字段）也会随着需要操作的数据一同被读取到内存中来，这样带来的问题由于大字段会占用较大的内存（相比其他小字段），使得内存利用率较差，造成更多的随机读取。
2、MEDIUMTEXT最大长度为16，777，215 LONGTEXT最大长度为4，294，967，295 使用方法：mysql中的text对应oracle中的clob，又分为TINYTEXT， TEXT， MEDIUMTEXT，LONGTEXT， 都是表示数据长度类型的一种。
3、mysql中text，longtext，mediumtext字段类型区别为：字节限制不同、I/O不同、行迁移不同。字节限制不同 text字段类型：text字段类型的字节限制为65535字节。
4、多大，没法说。数据量越大，速度越慢。因为mysql 是行存储模式，所以会把整行读取出来。text 储存了大量的数据。读取时，占了大量的io。所以会十分的慢。如果数据量有可能达到50万以上，一般此字段可以单独放到一个表里边。
