新乡网站建设-中国互联网站建设合理流程

新乡网站建设-中国互联,网站建设合理流程,网站开发项目报告,网站建设培训总结一、SelectDB索引体系全景图 SelectDB的索引体系分为两大阵营#xff1a;点查索引和跳数索引。这个分类方式很巧妙#xff0c;不是按数据结构分#xff0c;而是按查询场景分#xff0c;这让我想起了当年学MySQL时死记硬背B树、哈希索引的日子#xff0c;其实从使用场景出…一、SelectDB索引体系全景图SelectDB的索引体系分为两大阵营点查索引和跳数索引。这个分类方式很巧妙不是按数据结构分而是按查询场景分这让我想起了当年学MySQL时死记硬背B树、哈希索引的日子其实从使用场景出发更容易理解。1.1 点查索引精准定位的狙击手点查索引的核心思想是精准打击——通过索引直接定位到满足条件的行然后直接读取数据。这玩意儿在满足条件的行数较少时效果炸裂但在大范围查询时反而会拖后腿。前缀索引是SelectDB的默认玩法它按照排序键以有序方式存储数据每隔1024行创建一个稀疏索引。这个设计很聪明既保证了索引的稀疏性节省空间又能在查询时快速定位到目标数据块。但这里有个坑如果你的查询条件不包含排序键的前缀这索引就废了。我们曾经有个表按时间排序但业务经常按用户ID查询结果前缀索引完全没起作用全表扫描慢得让人想砸键盘。倒排索引是SelectDB的杀手锏也是我重点要说的。它给每个值建立了一个到行号的映射表等值查询时直接通过倒排表找到行号集合然后直接读取数据避免了逐行扫描。这玩意儿不仅支持等值查询还能加速范围过滤和文本关键词匹配。1.2 跳数索引批量过滤的扫荡机跳数索引的思路正好相反通过索引确定不满足条件的数据块直接跳过这些垃圾数据只读取可能满足条件的数据块再进行一次逐行过滤。这玩意儿在满足条件的行比较多时效果拔群。ZoneMap索引是自动维护的统计信息为每个数据文件和数据块记录最大值、最小值、是否有NULL、Sum等统计信息。这让我想起了MySQL的统计信息但SelectDB做得更彻底直接在数据块级别维护这些信息查询时直接通过统计信息判断是否满足条件不满足的直接跳过。BloomFilter索引和NGram BloomFilter索引则是针对特定场景的优化。BloomFilter适合等值查询NGram BloomFilter专门针对LIKE查询优化。但这里有个大坑BloomFilter有误判率虽然不会漏掉满足条件的数据但可能会把不满足条件的数据也拉进来导致额外的过滤开销。我们曾经在一个高并发的场景下滥用BloomFilter结果CPU直接飙到90%后来发现是BloomFilter的误判率导致大量无效数据被加载。二、实战踩坑那些年我们交过的学费2.1 案例一倒排索引的过度设计陷阱去年我们做日志分析系统表里有十几个字段业务同学说每个字段都可能被查询我脑子一热给所有字段都建了倒排索引。结果数据导入速度从每秒10万条降到每秒1万条磁盘空间占用翻了两倍。排查过程通过监控发现每次数据导入都要更新所有索引写放大严重。而且很多字段的基数很低比如状态字段只有几个值倒排索引的效果微乎其微。解决方案删掉低基数字段的索引只保留高基数字段用户ID、订单号等的倒排索引。同时把频繁更新的字段从倒排索引中移除改用ZoneMap索引。数据导入速度恢复到每秒8万条查询性能反而提升了。经验总结倒排索引不是越多越好高基数字段选择性0.1才值得建频繁更新的字段不要建倒排索引写放大太严重低基数字段用ZoneMap索引就够了空间占用小维护成本低2.2 案例二前缀索引的最左匹配陷阱我们有个订单表按(user_id, create_time)建了前缀索引。业务有个查询是WHERE create_time 2024-01-01结果走了全表扫描。排查过程执行计划显示没有使用索引因为查询条件没有包含user_id。这就是前缀索引的最左匹配原则——必须从最左列开始匹配不能跳过中间列。解决方案给create_time单独建了一个ZoneMap索引查询性能从10秒降到100毫秒。但这里有个权衡ZoneMap索引虽然能加速范围查询但会占用额外的存储空间。我们最终的选择是如果这个查询频率很高就单独建索引如果频率不高就接受全表扫描。经验总结前缀索引的字段顺序至关重要高频查询条件必须放在最左如果某个字段经常单独查询考虑单独建索引不要为了可能用到的查询而过度设计索引按需创建才是王道2.3 案例三BloomFilter的误判率陷阱我们有个用户行为表每天写入上亿条数据给user_id建了BloomFilter索引。结果发现某个查询的响应时间波动很大有时候几十毫秒有时候几百毫秒。排查过程通过监控发现当BloomFilter误判率较高时会加载大量无效数据块导致额外的过滤开销。虽然BloomFilter的误判率可以配置但降低误判率会增加内存占用。解决方案对于user_id这种高基数字段我们改用了倒排索引。虽然倒排索引的存储空间更大但查询性能更稳定。对于低基数字段如性别、状态继续使用BloomFilter因为误判率对性能影响不大。经验总结BloomFilter适合低基数字段高基数字段用倒排索引更合适BloomFilter的误判率需要根据业务场景调整不是越小越好监控BloomFilter的误判率定期评估是否需要调整配置三、索引设计黄金法则经过这些年的实战我总结了一套索引设计的黄金法则希望能帮大家少走弯路。3.1 索引选型决策树面对一个字段如何选择索引类型我画了个决策树是否高基数选择性0.1是 → 选择倒排索引否 → 进入下一步是否频繁更新是 → 选择ZoneMap索引否 → 进入下一步是否等值查询为主是 → 选择BloomFilter索引否 → 选择ZoneMap索引这个决策树不是绝对的需要根据具体业务场景调整。比如虽然某个字段基数低但如果查询频率极高也可以考虑用倒排索引。3.2 索引数量控制我们团队有个不成文的规定单表索引数量不超过5个。这不是硬性规定而是基于以下考虑写放大每个索引都会增加写入开销索引越多写入越慢存储成本索引占用存储空间大表可能翻倍维护成本索引越多优化器选择执行计划越复杂可能选错索引我们的做法是定期分析慢查询日志找出真正需要优化的查询针对性建索引。不要为了可能用到的查询而提前建索引那是过度设计。3.3 索引监控与调优索引不是一劳永逸的需要持续监控和调优。我们团队的做法慢查询监控每天分析慢查询日志找出TOP 10慢SQL索引使用率统计定期统计每个索引的使用频率删除长期不用的索引索引碎片整理对于频繁更新的表定期重建索引减少碎片执行计划分析对于关键查询定期检查执行计划确保走最优索引四、高级技巧那些教科书上不会告诉你的4.1 覆盖索引的妙用覆盖索引是指索引包含了查询所需的所有字段无需回表查询。这玩意儿用好了能让查询性能提升一个数量级。我们有个用户表经常查询SELECT user_id, name FROM users WHERE user_id ?。最初我们只给user_id建了索引查询时需要回表获取name字段。后来我们建了联合索引(user_id, name)查询直接从索引返回结果性能提升了5倍。关键点覆盖索引不是万能的它会增加索引大小需要权衡存储成本和查询性能。我们的经验是对于高频查询即使索引大一点也值得对于低频查询接受回表开销。4.2 索引下推ICP的威力索引下推是SelectDB的一个黑科技它允许在索引遍历过程中就对无法用索引过滤的WHERE条件进行判断从而减少回表次数。举个例子SELECT * FROM users WHERE name LIKE 张% AND age 30如果只有name的索引没有ICP的话会先通过name找到所有姓张的用户然后逐个回表检查age30。有了ICP在索引层就判断age30只有同时满足两个条件的才回表。我们曾经用ICP把一个查询的响应时间从500毫秒降到50毫秒效果惊人。但ICP不是自动启用的需要确保查询条件能被下推避免在索引列上使用函数或表达式。4.3 分区与索引的配合SelectDB支持分区表分区可以和索引配合使用实现更细粒度的数据管理。我们的做法是按时间分区比如按天然后在每个分区内建索引。这样查询时可以先通过分区裁剪过滤掉大部分数据再通过索引定位具体数据。对于历史数据查询效果尤其明显。但分区也有代价分区过多会增加元数据管理开销影响DDL操作性能。我们的经验是单表分区数不超过1000个超过这个数就要考虑分表了。五、避坑指南这些错误千万别犯5.1 索引失效的常见场景函数操作WHERE YEAR(create_time) 2024索引失效隐式类型转换WHERE user_id 123user_id是数字类型索引失效前导通配符WHERE name LIKE %张索引失效OR条件WHERE user_id 1 OR age 30如果age没有索引整个查询走全表扫描NOT条件WHERE status ! deleted索引可能失效5.2 索引维护的坑索引碎片频繁增删改会导致索引碎片定期重建索引是必要的统计信息过期数据分布变化后统计信息可能过期导致优化器选错索引索引冗余多个索引可能覆盖相同的查询需要定期清理冗余索引5.3 生产环境注意事项在线建索引大表建索引会锁表影响业务建议在业务低峰期操作索引变更回滚建索引失败可能导致表锁要有回滚预案监控告警索引变更后要密切监控系统负载发现问题及时回滚六、总结与展望SelectDB的索引体系非常强大但用好了是利器用不好就是自残。我的核心建议是索引设计三原则按需创建不要为了可能用到的查询而提前建索引高频优先优先为高频查询建索引低频查询可以接受全表扫描持续优化索引不是一劳永逸的需要定期监控和调优性能优化三步骤监控慢查询找出真正的性能瓶颈分析执行计划确认是否走最优索引针对性优化缺索引补索引索引失效改SQL