为什么要用 B-Tree
一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘 I/O 消耗，相对于内存存取，I/O 存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘 I/O 操作次数的渐进复杂度。换句话说，索引的结构组织要尽量减少查找过程中磁盘 I/O 的存取次数。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站！
微信- 支付宝
相关推荐
2022-06-29
mysql索引使用的注意事项
索引不会包含有NULL的列 只要列中包含有NULL 值，都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。 使用短索引 对串列进行索引，如果可以就应该指定一个前缀长度。例如，如果有一个 char（255） 的列，如果在前 10 个或 20 个字符内，多数值是唯一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和 I/O 操作。 索引列排序 MySql 查询只使用一个索引，因此如果 where 子句中已经使用了索引的话，那么 order by 中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作，尽量不要包含多个列的排序，如果需要最好给这些列建复合索引。 like 语句操作 一般情况下不鼓励使用 like 操作，如果非使用不可，注意正确的使用方式。like ‘%aaa%’ 不会使用索引，而 like ‘aaa%’ 可以使用索引。 不要在列上进行运算 不使用 NOT IN 、<>、！=操作，但 < , <= ，= ，> , >= , B...
2022-07-03
说说 SQL 优化之道
一些常见的 SQL 实践 负向条件查询不能使用索引 select from order where status!=0 and status!=1 not in/not exists # 都不是好习惯 可以优化为 in 查询： select from order where status in(2,3) 前导模糊查询不能使用索引 select from order where desc like '%XX' 而非前导模糊查询则可以： select from order where desc like 'XX%' 数据区分度不大的字段不宜使用索引 select from user where sex=1 原因：性别只有男，女，每次过滤掉的数据很少，不宜使用索引。 经验上，能过滤80%数据时就可以使用索引。对于订单状态，如果状态值很少，不宜使用索引，如果状态值很多，能够过滤大量数据，则应该建立索引。 在属性上进行计算不能命中索引 select from order where YEAR(date) < = &#x...
2022-07-07
数据库索引的原理
数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 BTree 及其变种 B+Tree。
2022-07-12
ObjectId 规则
时间戳 机器码 PID 计数器 0,1,2,3 4,5,6 7,8 9,10,11 前四位是时间戳，可以提供秒级别的唯一性。 接下来三位是所在主机的唯一标识符，通常是机器主机名的散列值。 接下来两位是产生 ObjectId 的 PID，确保同一台机器上并发产生的 ObjectId 是唯一的。 前九位保证了同一秒钟不同机器的不同进程产生的 ObjectId 时唯一的。 最后三位是自增计数器，确保相同进程同一秒钟产生的 ObjectId 是唯一的。
2022-07-01
说说分库与分表设计
垂直分表垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中。在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。 垂直分库垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。系统层面的“服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈，有利于系统的扩展维护。而数据库层面的拆分，道理也是相通的。与服务的“治理”和“降级”机制类似，我们也能对不同业务类型的数据进行“分级”管理、维护、监控、扩展等。 众所周知，数...
2022-07-10
limit 20000 加载很慢怎么解决
MySQL 的性能低是因为数据库要去扫描 N + M 条记录，然后又要放弃之前 N 条记录，开销很大 解决思路： 前端加缓存，或者其他方式，减少落到库的查询操作，例如某些系统中数据在搜索引擎中有备份的，可以用 es 等进行搜索 使用延迟关联，即先通用 limit 得到需要数据的索引字段，然后再通过原表和索引字段关联获得需要数据 select a.* from a,(select id from table_1 where is_deleted='N' limit 100000,20) b where a.id = b.id 从业务上实现，不分页如此多，例如只能分页前 100 页，后面的不允许再查了 不使用 limit N,M, 而是使用 limit N，即将 offset 转化为 where 条件。
评论
WalineDisqus
