SELECT 是 SQL 查询的核心操作，通过子句组合实现字段选取、过滤、聚合、连接、排序和分页；WHERE 筛行、HAVING 筛组；深分页宜用游标；相关子查询性能差；派生表须加别名。
SELECT 语句能做什么：不是“支持哪些操作”，而是“它本身就是查询操作的核心”
SELECT 不是容器式命令，不“支持”一堆操作；它是 SQL 查询的起点和主干。所有字段选取、过滤、聚合、连接、排序、分页，都通过它的子句（WHERE、GROUP BY、JOIN、ORDER BY、LIMIT 等）组合实现。单独写 SELECT * FROM t 是最简形式，加子句才构成完整查询逻辑。
-
SELECT后可跟字段名、表达式、函数（如COUNT()、CONCAT()、DATE_FORMAT()） - 表名可带别名（
FROM users u），字段也可用别名（SELECT name AS full_name） - 多表查必须显式声明连接方式（
INNER JOIN、LEFT JOIN），MySQL 不支持隐式逗号连接（除非明确需要笛卡尔积且理解风险）
WHERE 和 HAVING 的区别：一个筛行，一个筛组
WHERE 在分组前过滤原始数据行，作用于单行记录；HAVING 在 GROUP BY 之后过滤分组结果，常用于带聚合函数的条件（如 HAVING COUNT(*) > 5）。
-
WHERE中不能用聚合函数（WHERE SUM(amount) > 100报错） -
HAVING必须配合GROUP BY使用（除非整个查询无分组，此时HAVING退化为全局过滤，但语义模糊，不推荐） - 条件顺序影响性能：
WHERE越早排除无效行，后续计算越少；索引只能被WHERE利用，HAVING无法走索引
ORDER BY + LIMIT 组合分页：为什么 OFFSET 越大越慢
ORDER BY id ASC LIMIT 20 OFFSET 1000 看似简单，但 MySQL 仍需扫描前 1020 行才能跳过前 1000 行取后 20 行——OFFSET 不是“跳转指针”，而是“逐行计数”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 深分页场景应改用游标分页（
WHERE id > last_seen_id ORDER BY id LIMIT 20），依赖有序主键或唯一时间戳 -
ORDER BY字段必须有索引，否则排序会触发 filesort，内存/磁盘开销陡增 -
LIMIT若带两个参数（LIMIT 10,20），等价于LIMIT 20 OFFSET 10，含义相同，写法不同
SELECT 中的子查询：相关子查询容易拖垮性能
子查询可出现在 SELECT 列表（标量子查询）、FROM 子句（派生表）、WHERE 子句（IN / EXISTS）。其中相关子查询（即子查询引用外部表字段）每行执行一次，N 行就是 N 次查询。
- 避免在
SELECT列中写相关子查询（如SELECT id, (SELECT name FROM logs WHERE logs.user_id = users.id LIMIT 1) FROM users） -
EXISTS通常比IN更高效（尤其子查询结果可能含NULL时），因为找到第一条匹配就终止 - 派生表（
FROM (SELECT ...) AS t）必须带别名，否则报错Every derived table must have its own alias
MySQL 的 SELECT 灵活但不宽容：语法稍偏移就报错，逻辑稍复杂就变慢。真正难的不是记住支持什么，而是判断哪条路径在数据量、索引、事务隔离级别下实际可行。
