V2EX › wakzz 的所有回复 › 第 1 页 / 共 12 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 12

❮

❯

2023 年 4 月 2 日

回复了 woshipanghu 创建的主题 › OpenAI › 今天(4.2) openai 是不是在大面积封账号？

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

2023 年 4 月 1 日

回复了 LLaMA 创建的主题 › 程序员 › 为什么 twitter 不使用更省流量的 RESTful API？现在的 API 大部分流量都花在格式上

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

2021 年 4 月 25 日

回复了 daqin 创建的主题 › MySQL › 索引重复了？

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

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

@lewis89
@faqqcn
@Soar360

2021 年 4 月 19 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库存储在物理上是否连续，如果不连续那么如何保证读取速度？

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

2021 年 4 月 19 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库存储在物理上是否连续，如果不连续那么如何保证读取速度？

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

2021 年 4 月 19 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库存储在物理上是否连续，如果不连续那么如何保证读取速度？

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

2021 年 4 月 18 日

回复了 daoqiongsi1101 创建的主题 › MySQL › MySQL 大表有性能问题，但如果只查最近的数据呢？

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

2021 年 4 月 16 日

回复了 abersheeran 创建的主题 › 随想 › 人和人之间是经常是很难交流的

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

2021 年 4 月 16 日

回复了 abersheeran 创建的主题 › 随想 › 人和人之间是经常是很难交流的

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

2021 年 4 月 16 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库中的 null 对性能有什么影响？

mysql 的索引是基于预估成本进行选择的，is null 、is not null 、>、<、<>等查询条件并不影响索引的使用。多个索引存在时，mysql 只会选择它预估成本最低的索引，当然既然是预估，也存在 mysql 预估错误选择了非最优索引的情况。

2021 年 4 月 16 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库中的 null 对性能有什么影响？

@Justin13 is null 查询没问题，应该避免的是 or 这个查询关键字。

2021 年 4 月 16 日

回复了 LeeReamond 创建的主题 › 问与答 › 数据库中的 null 对性能有什么影响？

null 对索引有影响已经是老皇历了，mysql 的 innodb 引擎在 5.5 就已经做过优化了，null 字段和 not null 字段在索引查询方面几乎没有性能区别了。所以现在更关注 null 值和 not null 值对业务场景的落地问题。

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@GGGG430 不是，建议你别把别人当傻子。网上非实名制所以吧友们想到啥说啥，论点碰撞什么的日常情况了，但这年头出来混的谁没有点东西，你猜很多层不知道 b+树就离谱了。。。笑

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@GGGG430 基于的版本是 MySQL5.7 的 innodb，数据落盘后的 idb 文件。毫无实际应用价值的知识才是八股文，上面说 char 那是打快了

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@Narcissu5 1bit 真的可以忽略不计，与其讨论空间浪费，不如更关注 null 值、0 值和空字符串会不会引起业务歧义的问题。

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@dqzcwxb 是的，业务比性能更重要，默认非 null 值尤其是数值类型的 0 值在很多场景非常容易出现歧义。

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@GGGG430 我看过 innodb 的底层文件结构，空字符串的值本身不占用空间。但例如 varchar 等变长字段，都需要一个字符长度值来让程序知道该变长字段的字节长度。这个字符长度值本身占 1 到 2 个字节，而空字符串的字符长度值占用 1 个字节。
另外，我指的规范是人定的意思，不是说完全不用遵守规范，别非黑即白。而是按照实际的业务情况和历史原因，定义符合自己实际情况的规范。你这所指的完全没有规范就离谱了

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@zengming00 不用觉得，我看过底层数据实现结构，允许 null 值的列，都有一个比特位值来表示该列的值当前是否是 null 。

2021 年 4 月 15 日

回复了 codeismylife 创建的主题 › 问与答 › 有严格遵守 RESTful 范式的朋友吗？

RESTful 范式对于简单的场景还行，业务错误码稍微复杂点，就捉襟见肘了。

2021 年 4 月 15 日

回复了 AhogeK 创建的主题 › 问与答 › 因为把公司 Mysql 一堆带 null 字段优化非空带默认值被骂

@GGGG430 Null 值需要一个比特位做标识位，也就是说 8 个 Null 才用一个字节，而 int 类型一个 0 占用 4 字节，char 类型一个空值需要 1 字节的长度位表示，Null 值才是最省空间的方案。
另外你说的 mysql 规范，规范是人定的，很多场景下，Null 、空字符串是两种含义，技术是为了业务服务的，不能为了符合规范反而让业务更加复杂。

1 2 3 4 5 6 7 8 9 10 ... 12

❮

❯