wakzz 最近的时间轴更新
wakzz

wakzz

V2EX 第 500309 号会员,加入于 2020-07-22 15:05:49 +08:00
wakzz 最近回复了
361 天前
回复了 woshipanghu 创建的主题 OpenAI 今天(4.2) openai 是不是在大面积封账号?
自己注册的,账户正常使用
1. RESTful 经过这几年实践,大家都发现只适合简单业务场景
2. 文本结构格式浪费的带宽,相对于媒体连零头都算不上,而且即使文本浪费验证,开个 gzip 直接降低 90%的流量
2021-04-25 09:48:02 +08:00
回复了 daqin 创建的主题 MySQL 索引重复了?
楼上的不完全正确。如果当前场景下,没有 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%,当发生大量缓存命中失败导致大量磁盘读取时,更应该考虑如何提高缓存命中率,而不是物理磁盘碎片的问题;
2021-04-18 09:26:24 +08:00
回复了 daoqiongsi1101 创建的主题 MySQL MySQL 大表有性能问题,但如果只查最近的数据呢?
MySQL 的 innodb 引擎有个缓存池,专门缓存底层数据页。只考虑大表的性能问题,不考虑 SQL 优化的话,查询时在索引树能完全被缓存层命中的情况下,记录行被缓存层命中率越低,性能越慢。
这里字段缓存层指的是 innodb_buffer_pool,优先会缓存热点数据。因此在大表的查询中尽可能避免命中冷门数据,那么数据量对查询性能基本没有什么影响。
2021-04-16 10:02:34 +08:00
回复了 abersheeran 创建的主题 随想 人和人之间是经常是很难交流的
@abersheeran 这种人我还真遇到过,全程能以旁观视角来冷静讨论问题,膜拜
2021-04-16 09:25:52 +08:00
回复了 abersheeran 创建的主题 随想 人和人之间是经常是很难交流的
人与人之间的交流,本来就是冲突多于融合。不要抱着说服对方的心态,心平气和,取其精华学到东西就够了。当然实际操作时还是容易被喷到心态不平,然后有点失控,说到底还是自己修为不够。。。心累
2021-04-16 09:17:09 +08:00
回复了 LeeReamond 创建的主题 问与答 数据库中的 null 对性能有什么影响?
mysql 的索引是基于预估成本进行选择的,is null 、is not null 、>、<、<>等查询条件并不影响索引的使用。多个索引存在时,mysql 只会选择它预估成本最低的索引,当然既然是预估,也存在 mysql 预估错误选择了非最优索引的情况。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3712 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 10:38 · PVG 18:38 · LAX 03:38 · JFK 06:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.