我记的博客文章，更偏向于自己理解，相当于日记，笔记类型的，所以句子朴素，毫无结构章法可言，因此好朋友看见了笔墨低级大可笑笑，哈哈，重点在技术的积累，有不同见解或者更好的灵感多多留言或者直接微信讨论。我现在是完全把自己当成一个幼儿来学习的，不怕低级，不怕简单，重在打好基础，每篇文章都可能在日后随时修改完善。
以前在网上读过的技巧性文章，完全凭脑子记住，如果项目中刚好运用过，那还会有点印象。如果没实践，时间长了必定是忘光了。为了从此避免这种情况，还是要相信“好记性不如烂笔头”。
这种碎片化的文章为什么依然要存在，是因为关于优化这种命题，涉及的面太广，暂时也没有一本书之类的能完全给你系统的学习，所以针对这样的内容就先把收集到的有价值的方法先记录，等自己掌握的多了，再写总结性的，对比性的文章。
原文标题：在线查询系统性能优化
原文链接：http://tech.glowing.com/cn/online-query-system-performance-optimization/
别人的东西化成自己的，类似读薄书
场景是这样：查询数据库多张表的字段，综合成多字段的大表格给前端，要支持条件过滤，分页。当数据量大的时候可以用为这些不同表的字段综合设计一张“索引表”
| 原记录ID | 字段名 | 值 |
|---|---|---|
| sku1 | size | x |
| sku1 | color | red |
| sku1 | price | 55 |
| sku2 | size | m |
| sku2 | color | red |
| sku2 | price | 50 |
| sku3 | size | m |
| sku3 | color | green |
| sku3 | price | 60 |
如果要查询
SELECT record_id FROM SearchTable WHERE
record_id in
(SELECT record_id FROM SearchTable WHERE type='size' AND value in ('3','4', ...))
AND
record_id in
(SELECT record_id FROM SearchTable WHERE type='color' AND value in ('red','blue', ...))
AND
...
AND
type='time_created'
ORDER BY cast(value as unsigned) DESC
LIMIT 300 这种表的设计手法用的很普遍了，比如产品的属性，属性字段经常增减，有的产品种类可能具备属性ABC，有的可能ABD，一般都用这种横表转竖表的形式。
只不过原文提的是在一开始没有这种竖表的情况下，进行新增一张索引表，可以达到业务上代码实现的简单，并能极大加快查询速度，用这种方式，排序和分页也解决了。如果字段特别多，这种方法还能实现分步迁移，即先在索引表只冗余部分字段，用这部分字段快速缩小recordId范围，然后再继续原来的老逻辑。
如果不用这张索引表，原始的方法就需要多表连接
最后在这个基础上可以将查出的recordId去缓存查询，这样就完成了两步优化。
（这不是本文的重点，这篇重点在积累数据库表的设计对查询速度的优化）