SELECT * FROM table_name; 一行代码就能把整张表的数据拉出来，看起来简单到不能再简单。但很多新手刚上手就卡在第一关——表名写错、库没选对、权限不够，各种报错扑面而来。真正花时间的往往不是语法本身，而是搞清楚“表在哪、能不能读、数据是不是真的存在”。
怎么确认自己该查哪张表？
输入 SELECT * FROM users; 后看到 Table 'users' doesn't exist，别急着怀疑语法。大概率是库没连对，或者表名记错了大小写。
- 用
SHOW TABLES;看一眼当前库里有哪些表（MySQL 必备） - 用
SELECT current_database();（PostgreSQL）或SELECT DATABASE();（MySQL）确认当前所在数据库 - 表名区分大小写：Linux 下的 MySQL 默认严格区分，
Users和users是两个不同的表 - 如果表在别的 schema 里（比如
public.users），必须写完整路径：SELECT * FROM public.users;
为什么 SELECT * 在生产环境要谨慎？
省事是真的省事，但一旦上了生产，它带来的麻烦比省的那点力气多得多。
- 查大表时拖慢响应：一张表 50 个字段，还有
TEXT或BLOB，*把所有字段一股脑全拉过来，网络和内存开销直接翻倍 - ORM 映射出错：后端框架按字段顺序或名字映射结果，表结构一变（新增字段、调换顺序），代码可能无声无息地崩溃
- 权限暴露风险：表里藏着
password_hash、api_key这类敏感字段，*把它们全亮出来，哪怕你根本不需要 - 建议：明确写出需要的字段，比如
SELECT id, name, email FROM users;
查不到数据？先排除这三类常见干扰
SQL 执行成功，返回空结果集 —— 别急着说有数据。很可能是查询条件或环境在捣乱。
- 表是空的：用
SELECT COUNT(*) FROM table_name;先确认一下到底有没有数据 - 默认事务未提交：在 MySQL 的 InnoDB 或 PostgreSQL 里，另一个会话插了数据但没
COMMIT，当前会话自然查不到 - WHERE 条件误加：新手复制代码时经常漏删残留的
WHERE deleted_at IS NULL，而测试数据压根没设这个字段 - 注意 NULL 比较：
WHERE status = 'active'查不到status为NULL的行，必须用IS NULL单独判断
说到底，最耗时的不是 SELECT * 这几个字母，而是表在哪、有没有读权限、数据是否可见——这些环节往往比多敲几个字段名更考验耐心。
