如何从SQL数据库中提取数据：SELECT语句基础入门指南-SQL-PHP中文网

select无结果最常见原因不是表空，而是where条件过严、字段名错误或误以为默认有筛选逻辑；需检查值类型匹配、字符串引号、null用is null判断、order by与limit顺序及分页方式、连接层字符集与时区设置。

如何从sql数据库中提取数据：select语句基础入门指南

不是语法错，而是数据没“露脸”——SELECT 执行后返回空结果集，最常见原因不是表里没数据，而是条件太严、字段名写错、或默认没加 WHERE 却误以为该有筛选逻辑。

SELECT * 看起来最省事，但表里有 100 万行 + 大文本字段时，会拖慢查询、占网络带宽，开发阶段可以，上线前必须明确列名
字段名大小写敏感性取决于数据库：MySQL 在 Linux 下区分，Windows 下不区分；PostgreSQL 始终区分（除非用双引号包裹）；SQLite 默认不区分
如果用了 WHERE 却没结果，优先检查值类型是否匹配——比如把字符串 '2024-01-01' 和日期类型字段比较，在某些数据库里会静默转成 0 或 NULL，导致过滤失效

字符串漏掉单引号、NULL 用等号判断，是新手执行 SELECT 后“查不到却以为查到了”的高频原因。

字符串值必须用单引号包裹，WHERE name = 张三 是错的，正确写法是 WHERE name = '张三'；双引号在多数数据库中用于标识符（如字段名），不是字符串字面量
WHERE column = NULL 永远不成立，因为 NULL 表示“未知”，任何与 NULL 的比较都返回 UNKNOWN（即假）。要用 IS NULL 或 IS NOT NULL
模糊匹配别硬套 %：想查包含“订单”的记录，写 WHERE remark LIKE '%订单%' 没问题；但若字段是 CHAR(10) 类型，末尾空格会被补全，'订单 ' 和 '订单' 实际不相等，建议统一用 VARCHAR 或加 RTRIM()

ORDER BY 必须在 LIMIT 之前，否则语法报错；但更隐蔽的问题是：没 ORDER BY 就直接 LIMIT 10，每次执行可能返回不同 10 行——数据库不保证无序结果的稳定性。

LIMIT 不是 SQL 标准语法：MySQL / PostgreSQL 支持 LIMIT 10，SQL Server 要用 TOP 10，Oracle 12c+ 用 FETCH FIRST 10 ROWS ONLY
ORDER BY 字段如果存在重复值（比如多个用户注册时间相同），只靠它排序不能保证 LIMIT 结果可重现；稳妥做法是追加主键，例如 ORDER BY created_at DESC, id DESC
分页慎用 LIMIT 10000, 20：偏移量大时，数据库仍要扫描前 10000 行。高偏移场景建议用游标分页（基于上一页最后一条的 id 或时间戳继续查）

SELECT 出来的中文显示成问号、时间字段变成 1970-01-01，大概率不是 SQL 写错了，而是客户端连接时字符集或时区没对齐。

MySQL 连接时务必指定 charset=utf8mb4（不是 utf8），否则 emoji 和部分生僻中文存不进、也查不出来
PostgreSQL 默认按系统时区解析时间字面量，SELECT * FROM log WHERE time > '2024-01-01' 可能被解释成 UTC 时间，而你的数据是东八区存的。显式声明时区更可靠：'2024-01-01'::timestamptz AT TIME ZONE 'Asia/Shanghai'
有些 ORM（如 Python 的 SQLAlchemy）默认把 datetime 字段映射为 naive datetime（无时区），查出来的时间对象没有 tzinfo，后续做时区转换容易出错。连接参数里加 timezone=True 或手动设置时区绑定

实际查数据时，最难调试的往往不是 SELECT 本身，而是你没意识到数据库连接参数、字段类型定义、客户端编码这些“外围配置”已经悄悄改写了结果含义。