能用但多数时候不该用——它会解析全部列元数据、传输冗余字段、阻碍执行计划优化，易引发列名冲突、ORM映射错乱等问题，仅限调试或结构极小稳定时使用。
SELECT * 在真实查询中到底能不能用
能用，但多数时候不该用——不是语法错误，而是隐性成本太高。它会让数据库多做三件事：解析全部列元数据、传输冗余字段、让执行计划更难优化。
常见错误现象：SELECT * 在视图或 JOIN 后返回重复列名（比如两个表都有 id），导致应用层取值混乱；ORM 自动映射时字段顺序错位，甚至静默丢数据。
- 只在临时查数、调试、或明确知道表结构极小且稳定时用（比如
users表只有 4 列且半年不加字段） - 生产接口、报表 SQL、ETL 脚本里一律显式写列名，哪怕多敲几下
- 如果真要“所有列”，先用
SELECT column_name FROM information_schema.columns WHERE table_name = 'xxx'拉出来再拼，而不是靠星号偷懒
MySQL 和 PostgreSQL 对 SELECT * 的处理差异
表面一样，底层行为不同：MySQL 在准备阶段就展开 * 成具体列，而 PostgreSQL 把它留到执行期才解析，这对视图和权限控制影响明显。
使用场景举例：你在 PostgreSQL 里给用户授予 SELECT 权限到某视图，但该视图定义含 SELECT *，一旦基表加了新列，用户立刻能查到——这常被当成权限绕过漏洞。
- MySQL 中
*展开后，如果后续 ALTER TABLE ADD COLUMN，旧的预编译语句不会自动包含新列 - PostgreSQL 中
*是“活”的，视图或函数里用它等于每次重查系统表，性能略差但语义更直观 - 两者都不支持对
*做别名（SELECT * AS data FROM t是语法错误）
SELECT * 和 COUNT(*) 性能完全不是一回事
这是最常被混淆的点：COUNT(*) 是统计行数，优化器知道可以走索引或元数据，基本不读数据页；而 SELECT * 必须把每行所有字段从磁盘或缓冲区捞出来，IO 和网络开销指数级增长。
错误现象：有人看到慢查询日志里 SELECT * 执行时间 2.3s，就以为加个 COUNT(*) 索引就能解决——其实根本不是同一类问题。
-
COUNT(*)在 InnoDB 里通常走二级索引最小叶子节点，速度飞快 -
SELECT *即使加了覆盖索引，只要没包含所有字段，仍要回表，且结果集越大越卡 - 如果只是判断“有没有数据”，用
EXISTS (SELECT 1 FROM t WHERE ...)比SELECT * FROM t WHERE ... LIMIT 1更轻量
ORM 自动生成 SELECT * 的隐患怎么破
像 Django 的 Model.objects.all()、SQLAlchemy 的 session.query(Model) 默认生成 SELECT *，看着方便，上线后容易拖垮数据库。
关键不是禁用 ORM，而是控制输出粒度：Django 用 .values('id', 'name')，SQLAlchemy 用 session.query(Model.id, Model.name)，都能绕过星号。
- 避免在 API 序列化层直接传
model_instance.__dict__，字段可能含敏感内容或大文本 - 如果必须用全量对象，至少加上
.only('id', 'name', 'status')（Django）或.options(load_only('id', 'name'))（SQLAlchemy） - 数据库连接池监控里重点看平均结果集大小，突然飙升往往就是某处漏写了字段白名单
真正麻烦的从来不是语法会不会写，而是团队里没人 review SQL 是否用了 *，或者 review 时觉得“反正就查十行，无所谓”。等数据量涨十倍、字段加到二十个、JOIN 三层之后，再改就不是改一行的事了。
