phpmyadmin 不执行 like 查询，慢因在 mysql 层；优化应聚焦索引（如前缀索引、fulltext）、sql 设计（避免前导 %）及工具选型（大表用命令行或专业客户端）。
phpmyadmin 本身不执行 like 查询，它只是把你的 sql 传给 mysql。所以“phpmyadmin 执行 like 查询很慢”，本质是 mysql 在执行 like 时慢，而 phpmyadmin 因为要渲染结果、做字段解析、生成链接等额外工作，放大了这种延迟感。优化方向必须聚焦在 sql 和 mysql 层，而非 phpmyadmin 界面设置。
确认是否真被索引跳过
MySQL 对 LIKE 能否用上索引，只看通配符位置，和 phpMyAdmin 无关。你写的 WHERE name LIKE '%张%' 就算加了索引也无效；但 WHERE name LIKE '张%' 可以命中 B+ 树索引。
- 用
EXPLAIN看执行计划：type是ALL就代表全表扫描，key字段为空说明没走索引 - 如果字段是长文本（如
VARCHAR(255)），但实际前 10 个字符就足够区分，可建前缀索引：CREATE INDEX idx_name_prefix ON users(name(10)); - 别在 phpMyAdmin 的 SQL 窗口里直接跑
SELECT * FROM huge_table WHERE col LIKE '%xxx%'—— 这不是界面问题，是 SQL 本身设计缺陷
用 FULLTEXT 替代复杂模糊搜索
当业务需要真正“包含某词”（非前缀）且字段内容较长（标题、简介、正文），LIKE '%keyword%' 是反模式。MySQL 的 FULLTEXT 索引专为此类场景设计，性能差距可达数量级。
- 仅支持
MyISAM或InnoDB（MySQL 5.6+），且字段需为CHAR/VARCHAR/TEXT - 建索引：
ALTER TABLE articles ADD FULLTEXT(title, content); - 查法必须换：
SELECT * FROM articles WHERE MATCH(title, content) AGAINST('苹果手机' IN NATURAL LANGUAGE MODE); -
AGAINST()不支持通配符拼接，也不能用OR混合其他条件——这是功能边界，不是 bug
phpMyAdmin 配置不解决根本慢，但能避免雪上加霜
即使 SQL 已优化，phpMyAdmin 默认行为仍可能让一次慢查询变得更糟：它会尝试读取全部结果、逐行转义、生成编辑链接、统计字段长度……这些在万行以上数据时 CPU 占用远超 MySQL 本身。
- 强制限制每页行数：
$cfg['MaxRows'] = 50;（写在config.inc.php的$cfg数组内，别放 if 块里） - 截断长字段显示：
$cfg['LimitChars'] = 500;，防止 TEXT 字段拖垮响应 - 关掉右侧权限面板：
$cfg['Servers'][$i]['ShowDatabasesNavigationAsTree'] = false; - 执行分析类查询时，勾选“显示无格式”（对应配置
$cfg['SQLQuery']['AsIs'] = true;），跳过 HTML 渲染开销
别让 phpMyAdmin 承担它不该干的活
对百万级以上表做模糊查询、导出、清洗或分页浏览，phpMyAdmin 是最差选择。它的定位是轻量管理，不是数据分析终端。
- 用命令行：
mysql -u user -p -e "SELECT id,name FROM users WHERE name LIKE '李%' LIMIT 1000;" db_name > out.csv - 导出大结果集用
SELECT ... INTO OUTFILE，比 phpMyAdmin “导出”快 5–10 倍 - 日常开发用 DBeaver/Navicat，它们对大结果集有流式加载、列过滤、内存控制等原生支持
- 线上环境禁止用 phpMyAdmin 执行未加
LIMIT的SELECT—— 这不是慢，是生产事故前兆
真正卡住的从来不是 phpMyAdmin 的按钮，而是那条没加索引、没限行、还带着前导 % 的 LIKE 语句。工具只是镜子，照出的是 SQL 设计和数据模型的真实水位。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
