SQL中如何获取所有列的数据：SELECT -星号用法与性能影响

能用但多数时候不该用——它会解析全部列元数据、传输冗余字段、阻碍执行计划优化，易引发列名冲突、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 和网络开销指数级增长。 VWO 一个A/B测试工具