MySQL如何解决深度分页问题？ 在 MySQL 开发中，除了计数场景，深度分页（即 LIMIT offset, size 中 offset 值极大的分页查询）也是高频遇到的性能问题。比如"查询第1000页数据，每页10条"（LIMIT 9990, 10），常会出现查询缓慢的情况。下面详细讲解深度分页的问题根源及解决方案。1. 深度分页的问题根源先明确常规分页的实现方式：使用 LIMIT offset, size，其中 offset 表示跳过前 N 条数据，size 表示取 N 条数据。问题核心： 当 offset 极大时（如 9990），MySQL 需要先扫描并跳过前 9990 条数据，再取 10 条数据。即使查询条件有索引，也需要遍历索引到第 9990 条位置，才能定位到目标数据，导致 IO 开销大、查询效率低。示例（低效查询）：-- 查询第1000页数据，每页10条，offset=9990 SELECT id, name FROM test_table LIMIT 9990, 10; -- 问题：MySQL需扫描前9990条数据并跳过，仅返回最后10条，资源浪费严重2. 解决方案（按适用场景排序）方案1：基于主键/索引排序+条件过滤（推荐，适用大部分场景）核心思路： 利用主键或有序索引的连续性，通过 WHERE 条件直接定位到"上一页最后一条数据"，替代 offset 跳过数据。要求查询结果必须按主键或有序索引字段排序。实现步骤：分页查询时，记录上一页最后一条数据的主键/索引字段值（如最后一条数据的 id=9990）；下一页查询时，通过 WHERE 主键 > 上一页最后主键 直接过滤前 9990 条数据，再用 LIMIT size 取数。示例（优化后查询）：-- 第1页查询（无offset，直接取前10条） SELECT id, name FROM test_table ORDER BY id ASC LIMIT 10; -- 记录第1页最后一条数据的id=10 -- 第2页查询（通过id>10过滤前10条，无需offset） SELECT id, name FROM test_table WHERE id > 10 ORDER BY id ASC LIMIT 10; -- 记录第2页最后一条id=20 -- 第1000页查询（直接过滤前9990条，效率极高） SELECT id, name FROM test_table WHERE id > 9990 ORDER BY id ASC LIMIT 10;优点： 利用索引快速定位，无需扫描跳过的数据，查询效率稳定且高效缺点： 仅支持"下一页"查询，不支持直接跳转到任意页（如直接跳第1000页，需知道第999页最后一条的 id）方案2：游标分页（适合滚动加载场景）核心思路： MySQL 的 CURSOR（游标）本质是一个指向查询结果集的指针，可通过游标逐页读取数据，避免 offset 的低效扫描。适合"滚动加载更多"（如 APP 下拉加载）的场景，不支持跳页。实现步骤：-- 1. 声明游标（指定查询条件和排序方式） DECLARE cur_page CURSOR FOR SELECT id, name FROM test_table ORDER BY id ASC; -- 2. 打开游标 OPEN cur_page; -- 3. 读取数据（每次读取10条，即一页） FETCH cur_page INTO @id, @name; -- 逐行读取，可循环读取10条作为一页 -- 4. 关闭游标 CLOSE cur_page;优点： 适合大量数据的滚动加载，效率稳定缺点： 不支持直接跳页，语法较复杂，需在存储过程中使用方案3：预计算汇总表（适合静态/低频更新数据）核心思路： 如果数据是静态的（如历史订单、归档数据）或更新频率极低，可提前预计算分页所需的"分页标记"（如每10条数据的最大主键），存储在汇总表中。查询时直接从汇总表获取目标页的标记，再查询主表数据。实现示例：-- 1. 创建汇总表（存储每页最后一条数据的id和页码） CREATE TABLE page_summary ( page_num INT PRIMARY KEY, -- 页码 last_id INT -- 该页最后一条数据的id ); -- 2. 预插入数据（可通过定时任务更新） INSERT INTO page_summary VALUES (1, 10), (2, 20), ..., (1000, 10000); -- 3. 查询第1000页数据（先查汇总表，再查主表） SELECT last_id FROM page_summary WHERE page_num = 999; -- 得到第999页最后id=9990 SELECT id, name FROM test_table WHERE id > 9990 ORDER BY id ASC LIMIT 10;优点： 查询速度极快，适合大数据量静态数据缺点： 不适合动态更新数据，需维护汇总表（增加存储和维护成本）方案4：限制分页深度（业务层面优化）核心思路： 从业务角度限制用户的分页深度，避免用户查询过深的页码。比如"最多支持查询前100页数据"，超过则提示"数据过多，请缩小查询范围"。实现示例：-- 限制offset最大值为9990（即最多100页） SELECT id, name FROM test_table WHERE offset <= 9990 LIMIT #{offset}, #{size};优点： 简单易实现，从根源减少深度分页查询缺点： 有业务局限性，不适用于必须支持深分页的场景（如后台数据导出）3. 方案选择总结方案适用场景核心优势局限性主键/索引条件过滤大部分动态数据分页（如列表查询）效率高、实现简单、兼容性好不支持直接跳页游标分页APP滚动加载、大量数据逐页读取效率稳定、适合大数据量不支持跳页、语法复杂预计算汇总表静态/低频更新数据（如归档、报表）查询速度极快需维护汇总表、不支持动态数据限制分页深度业务允许限制分页范围（如前台列表）实现简单、无性能开销业务局限性大补充提示： 深度分页优化的核心是"避免扫描跳过无关数据"，无论哪种方案，都需确保查询条件中的排序字段有索引（如主键默认有索引），否则仍会出现全表扫描，优化失效。

MYSQL和POSTGRESQL怎么选？看完这篇就懂了 先搞懂：MySQL和PostgreSQL的核心差异如果把数据库比作"工具箱"，MySQL像个"经济适用的老伙计"——够用、稳定、上手快，适合大多数基础需求；而PostgreSQL更像个"全能工程师"，功能更灵活、扩展性更强，适合想"玩出花"的场景。具体差异主要在三点：1. 数据类型：灵活度差了一个LEVELMySQL的字段类型比较"保守"，常用的VARCHAR、INT、DATETIME都能搞定，但遇到复杂需求（比如存JSON格式的标签、数组类型的分类）就有点吃力——虽然MySQL 5.7后支持了JSON字段，但本质是存文本，查询效率低，还没法直接对JSON里的内容建索引。PostgreSQL则像个"数据百宝箱"：除了基础类型，它原生支持JSONB（二进制优化的JSON，能直接索引）、ARRAY（数组）、RANGE（时间/数值范围）甚至地理信息类型（GEOMETRY）。Halo博客里常见的"自定义文章元数据"（比如给文章打多个标签、存阅读量趋势），用PostgreSQL的JSONB存，查询时直接->>取字段，效率比MySQL高很多。2. 并发性能：多用户协作更丝滑博客最怕啥？博主和协作者同时改文章，结果"谁的版本覆盖了谁"。这涉及到数据库的"并发控制"。MySQL靠"行锁"解决冲突：你改一行，这行就被锁住，其他人得等。高并发下容易卡成"排队改稿"。PostgreSQL用的是"MVCC"（多版本并发控制）：你改数据时，系统自动存一个旧版本；别人读的时候直接读旧版本，你改完再替换。读不挡写，写不挡读，多人同时编辑Halo博客，几乎感受不到延迟。3. 扩展能力：POSTGRESQL更"能折腾"Halo的魅力在于"可定制"——从主题到插件，很多人会想加新功能（比如给文章加地理位置标签、用图表统计阅读量）。这时候数据库的"扩展性"就关键了。MySQL的扩展主要靠插件，但数量少且功能集中（比如慢查询监控）；PostgreSQL的插件生态像"应用商店"：地理信息插件PostGIS、全文检索增强插件zhparser（中文分词）、甚至机器学习插件都能装。Halo如果后期想加"附近文章推荐""智能标签"这类功能，PostgreSQL几乎能无缝支持。Halo为啥更推荐PostgreSQL？回到Halo本身，它是个"轻量但长情"的博客系统——你可能从个人记录用到团队协作，从几篇文章写成几百篇。这时候PostgreSQL的优势会更明显：自定义字段友好：Halo支持给文章加自定义字段（比如"来源""阅读难度"），用PostgreSQL的JSONB存这些字段，既能灵活扩展，又能高效查询（比如按"阅读难度=中等"筛选文章）。多用户协作不卡顿：博主+编辑+评论管理员的多角色场景，PostgreSQL的MVCC能避免"改稿打架"，编辑体验更流畅。长期稳定有保障：PostgreSQL的ACID事务更严格（比如转账操作"要么全成功，要么全回滚"），数据一致性比MySQL更可靠。毕竟博客数据是"数字资产"，稳定比"够用"更重要。总结：按需选，但HALO更适配POSTGRESQL如果是纯个人博客，文章少、功能简单，MySQL完全够用（毕竟安装配置更省事）；但如果想让Halo"长大"——加自定义功能、多人协作、未来扩展，PostgreSQL的灵活度和稳定性会更适配。毕竟，博客是"写给未来的自己"的，选个能陪你"折腾"的数据库，才不算辜负那些深夜敲字的灵感呀～（注：Halo官方文档对两种数据库均支持，但社区反馈PostgreSQL在复杂场景下表现更优，可根据需求选择。）

数据库报错：SELECT list is not in GROUP BY clause mysql5.7使用group by出现错误：[Err] 1055 - Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'test.score.c_id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_byphpstudy解决方法：在phpstudy的mysql.ini文件中添加sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"