百度文库 旅游网站建设方案书制作wordpress主题

百度文库 旅游网站建设方案书,制作wordpress主题,河南seo网站多少钱,wordpress 前台登录线上出了个离谱问题#xff1a;运营同学在后台导出近 3 个月订单时#xff0c;点击分页到第 100 页#xff0c;直接把数据库查崩了。排查后发现#xff0c;代码里写了 LIMIT 9900, 100#xff0c;在分库分表场景下#xff0c;这行 SQL 相当于让 8 个分片各查 1 万条数据运营同学在后台导出近 3 个月订单时点击分页到第 100 页直接把数据库查崩了。排查后发现代码里写了LIMIT 9900, 100在分库分表场景下这行 SQL 相当于让 8 个分片各查 1 万条数据再拉到应用层内存排序直接把内存溢出了。其实分库分表的分页查询藏着很多反常识的奇技淫巧但这些技巧都有严格的适用边界用错了反而会埋坑。我来分享 3 个实战中验证过的骚操作。分库分表 LIMIT 是性能杀手单表分页用LIMIT offset, size没问题但分库分表后数据散在多个分片里比如你要查LIMIT 10000, 10第 1001 页会发生两件离谱的事全分片扫描每个分片都要执行LIMIT 0, 10010因为不知道其他分片的数据分布只能把前 10010 条都查出来避免漏数据内存爆炸排序假设 8 个分片每个返回 10010 条共 8 万多条数据全拉到应用层排序再截取第 10000-10010 条。内存和 CPU 直接飙红我之前见过最夸张的案例offset100000时一个分页请求耗时 12 秒直接触发服务熔断。所以我们下边要讲的都是绕开全分片扫描 内存排序但每个方案的适用场景天差地别核心原则不盲目追高性能先看业务场景是否匹配。锚点分页锚点分页性能最优但仅限加载更多场景。这是我最常用的技巧核心思路是用数据本身的有序字段当锚点替代 offset比如按自增 ID 或时间戳分页。但注意不是所有有序字段都能用必须满足分片内 分片间都有序。按 ID 范围分片假设订单表按 ID 范围分 3 个分片分片 1ID 1-10000分片内有序且小于分片 2 的 ID分片 2ID 10001-20000同理分片 3ID 20001-30000同理要查第 2 页10 条 / 页步骤如下查第 1 页时执行ORDER BY id DESC LIMIT 10拿到最后一条数据的 ID 是last_id100这个 ID 就是锚点查第 2 页时直接用WHERE id 100 ORDER BY id DESC LIMIT 10查第 3 页时再用第 2 页最后一条的 ID比如 90当锚点执行WHERE id 90 ORDER BY id DESC LIMIT 10。为什么性能高每个分片都能独立执行WHERE id xxx LIMIT 10只返回 10 条数据不用查前 N 条。比如查第 1001 页每个分片也只返回 10 条汇总后排序取 10 条网络和内存开销直接降为原来的 1/1000。必避的 2 个坑别用哈希分片如果按ID mod 3哈希分片分片 1 的 ID 可能是 3、6、9...分片 2 是 1、4、7...此时 ID 全局有序但分片内无序执行WHERE id 100仍需全量扫描分片内数据退化为 “内存聚合”不支持跳页只加载更多下一页依赖上一页的锚点无法直接从第 1 页跳到第 100 页。但可以通过产品设计规避比如抖音、小红书的列表都是加载更多用户体验反而更好。分片标记法刚才的锚点分页不支持跳页但有些场景比如后台管理系统又必须要跳页怎么办我之前在电商后台做订单导出时用过分片标记法核心是给每个库、表记录数据范围和总量快速定位目标页在哪个分片。分片标记法支持跳页但必须控制元数据一致性。用法示例假设订单表按用户 ID 范围分 2 库每库按时间分 12 表如库 1 - 表 202401、库 1 - 表 202402...先在 Redis 里维护 库、表级别的元数据库 - 表起始 ID结束 ID数据总量库 1 - 表 202401150005000库 1 - 表 2024025001120007000库 2 - 表 20240112001180006000..........180006000现在要查LIMIT 15000, 10第 1501 页步骤如下查元数据定位库、表计算累计数据量库 1 - 表 2024015000 库 1 - 表 2024027000 12000 15000再加上库 2 - 表 202401 的 6000累计 1800015000所以目标在库 2 - 表 202401计算表内偏移量表内偏移量 15000 - 12000 3000所以库 2 - 表 202401 执行LIMIT 3000, 10直接返回结果因为库、表按 ID 有序查询结果就是全局第 15000-15010 条不用汇总其他分片。必避的 2 个坑1.元数据必须实时但不能强同步数据新增、删除时要同步更新 Redis 元数据但高并发下不能加分布式锁会卡住业务建议用定时 增量日志每 5 分钟全量统计一次同时记录增量如新增 100 条、删除 10 条查询时叠加增量若允许最终一致性如后台查询允许误差 10 条这个方案很稳若要强一致只能放弃跳页用锚点分页2.不支持非分片键排序如果要按支付时间排序分片键是用户 ID支付时间在 “库 - 表” 内无序元数据无法定位仍需全分片扫描。反向分页反向分页仅适用于查最后 1 页别乱用这个技巧最反常识但局限性也最大。如果要查最后几页数据比如用户查最早的订单用普通分页会查LIMIT 9990, 10但可以反向查避开大 offset。仅查最后 1 页假设订单表按 ID 范围分片总数据量 10000 条1000 页10 条 / 页要查最后 1 页ID 9991-10000反向查锚点执行ORDER BY id ASC LIMIT 10拿到最前面 10 条的 ID1-10取最大 ID 作为反向锚点10查最后 1 页执行WHERE id 10 ORDER BY id DESC LIMIT 10拿到的就是 ID 10000-9991最后 10 条调整顺序如果需要正序展示把结果再倒过来即可。为什么能生效因为LIMIT 0, 10比LIMIT 9990, 10快 100 倍. 每个分片查前 10 条数据汇总后取最大的 10 个 ID 作为锚点再查大于锚点的数据避免了大 offset 扫描。必避的 2 个坑仅适用于最后 1 页如果要查倒数第 10 页第 991 页按这个逻辑无法定位锚点需要知道第 9900 条数据的 ID只能查倒数第 1 页数据不能有大量删除如果中间有大量 ID 被删除如 ID 5000-8000 都被删了总数据量变为 7000 条此时WHERE id 10 ORDER BY id DESC LIMIT10拿到的是 7000-6991正确但如果删除的是最后 100 条ID 9901-10000总数据量变为 9900 条需要重新计算反向锚点增加复杂度。说在后边其实分库分表分页的核心不是炫技而是在业务和技术之间找平衡。能通过产品设计规避跳页用加载更多就优先用锚点分页性能最优必须跳页就用分片标记法接受最终一致性实在没办法才考虑中间件如ShardingSphere的全局排序。