wakzz

自己注册的，账户正常使用

1. RESTful 经过这几年实践，大家都发现只适合简单业务场景
2. 文本结构格式浪费的带宽，相对于媒体连零头都算不上，而且即使文本浪费验证，开个 gzip 直接降低 90%的流量

楼上的不完全正确。如果当前场景下，没有 store_id 与主键 id 的覆盖索引查询场景，那么第一个索引删掉没问题。

但如果存在 store_id 与主键 id 的覆盖索引查询场景，或者例如 `where store_id order by 主键 id` 之类的查询，那么第一个索引还是不能删掉的。


@lewis89
@faqqcn
@Soar360

@dblpx 是的，innodb 默认 16K 一个数据页，然后默认每 64 个数据页构成一个组，组就是物理磁盘空间申请的最小单位。

@LeeReamond mysql 的 innodb 的缓存层是直接缓存的磁盘文件，不是对 sql 结果的缓存，而是对物理文件分片(每个分片默认 16K)的缓存。
比如一个查询涉及到多条行记录，innodb 会先去索引树找到对应记录的具体物理文件分片位置，然后到缓存层尝试命中这几条记录所在的物理文件分片。缓存命中不到后再去物理磁盘上读取文件分片数据，然后再在内存中聚合查询处理操作。

1. MySQL 的 innodb 是通过预先分配磁盘空间的形式来减少碎片化问题，默认是每次申请 1M 大小的连续磁盘；
2. 每 1M 的连续读操作才遇到一次物理不连续，导致的性能消耗影响相对较小，甚至可以忽略；
3. 事实上数据库都有一个缓存层来缓存物理文件数据，性能正常的 innodb 引擎的缓存命中率要不低于 99%，当发生大量缓存命中失败导致大量磁盘读取时，更应该考虑如何提高缓存命中率，而不是物理磁盘碎片的问题；

MySQL 的 innodb 引擎有个缓存池，专门缓存底层数据页。只考虑大表的性能问题，不考虑 SQL 优化的话，查询时在索引树能完全被缓存层命中的情况下，记录行被缓存层命中率越低，性能越慢。
这里字段缓存层指的是 innodb_buffer_pool，优先会缓存热点数据。因此在大表的查询中尽可能避免命中冷门数据，那么数据量对查询性能基本没有什么影响。

@abersheeran 这种人我还真遇到过，全程能以旁观视角来冷静讨论问题，膜拜

人与人之间的交流，本来就是冲突多于融合。不要抱着说服对方的心态，心平气和，取其精华学到东西就够了。当然实际操作时还是容易被喷到心态不平，然后有点失控，说到底还是自己修为不够。。。心累