点击列头排序失效时，应先取消“使用 JavaScript 排序”选项以触发带 ORDER BY 的后端查询；若仍无效，需在 SQL 中显式添加 ORDER BY 字段并确保其位于 LIMIT 之前，同时中文排序异常需通过 COLLATE 指定 utf8mb4_unicode_ci 等合适校对规则。
点击列头排序失效时怎么救？
直接点列标题排序没反应，大概率是启用了“排序列”功能但没生效。phpmyadmin 的排序依赖于 order by 语句生成，而默认查询结果页的排序按钮只对当前页面数据做前端重排（仅限小数据量），一旦结果超过 $cfg['maxrows']（默认 30）或启用了“使用 javascript 排序”，就可能不触发后端重查。
- 先确认右上角是否勾选了
使用 JavaScript 排序—— 勾选后是纯前端排序，不发新请求，大数据量下不准也不翻页；取消勾选才能触发带ORDER BY的新查询 - 如果已取消但仍无效，检查 SQL 查询本身是否含
LIMIT且没写ORDER BY：phpMyAdmin 不会自动补排序字段，必须显式声明，否则点击列头只是前端抖动一下 - 临时补救：在当前 SQL 窗口里手动加
ORDER BY `column_name` ASC，再执行
想在已有结果里再筛关键词，但不想重跑 SQL？
phpMyAdmin 没有 Excel 那种“筛选器”面板，所谓“二次筛选”本质是两种操作：前端过滤（快但不可靠）或构造新 WHERE（准但要重查）。
- 前端快速过滤：结果页右上角有
筛选输入框（带放大镜图标），输入关键词后按回车，它会对**当前页所有字段文本内容**做模糊匹配（类似LIKE '%keyword%'），不发请求、不翻页、不改变原始 SQL —— 适合临时找某条记录，但跨页数据看不见 - 真二次筛选必须改 SQL：比如原查
SELECT * FROM users，现在只想看 status=1 的，就得改成SELECT * FROM users WHERE status = 1，然后点执行 - 注意
筛选框对数字/日期字段支持弱，比如搜2024可能匹配到时间戳、ID、年份，无法指定字段
排序中文字段乱码或顺序错，怎么调？
点中文列头排序后出现“啊、中、一、张”这种非字典序，不是 bug，是字符集 collation 不匹配导致的排序规则错误。
- 查字段实际 collation：点表结构页，看对应列的
Collation值，如果是utf8mb4_general_ci，中文排序基本不可靠；应改为utf8mb4_unicode_ci或更准的utf8mb4_zh_0900_as_cs（MySQL 8.0+） - 临时修复排序：在 SQL 查询里强制指定 collation，例如
ORDER BY name COLLATE utf8mb4_unicode_ci ASC - 别用
utf8字符集——它最多存 3 字节，微信昵称、emoji 全变问号，后续排序更混乱
导出前想按某字段倒序，但导出按钮不认当前排序？
phpMyAdmin 导出始终基于原始 SQL 执行结果，不会记住你点过几次列头。导出按钮旁边那个“排序”下拉菜单只是前端提示，不改变导出逻辑。
- 导出前务必手动修改 SQL：把
ORDER BY加到查询末尾，例如SELECT * FROM logs ORDER BY created_at DESC LIMIT 1000 - 如果用了
LIMIT，记得把ORDER BY放它前面，否则 MySQL 5.7+ 会报错This is not allowed in a UNION, subquery or in a SELECT with LIMIT - 导出格式选
CSV时，若字段含换行符或逗号，务必勾选使用引号包裹字段，否则 Excel 打开全错行
实际用起来，最常被忽略的是：前端筛选框和列头排序走的是两套逻辑，一个不动 SQL，一个要重发请求，混用时根本不知道当前看到的数据是哪一层过滤的结果。尤其当数据量大、分页多、又开了 JavaScript 排序，很容易误判数据完整性。
立即学习“PHP免费学习笔记（深入）”；
