姑苏薛衡芜有不少人私信问我，数据库这块到底该怎么学，尤其是“SQL核心对象”这个概念，听起来很大，真去翻书又不知道从哪下手。这篇文章我打算用自己的实际经验，把表和字段、索引、视图、存储过程、函数、触发器这些核心对象一次讲透，顺带把我这些年踩过的坑、排查过的问题一并抖出来。内容尽量贴近真实开发场景，适合刚入门的新人，也适合写了几年SQL却总觉得缺根弦的兄弟。
1. 理解SQL核心对象：一张图看懂数据库的骨架
1.1 为什么先搞懂核心对象，而不是直接背SQL语法
刚开始学SQL的时候，我也干过一件蠢事：捧着本《SQL必知必会》从头背到尾，SELECT、WHERE、JOIN背得滚瓜烂熟，真到写业务的时候却发现完全不够用。后来才慢慢悟出来一个道理——SQL语法只是“怎么说”，而核心对象才是“说什么、对谁说”。
就好比你学做菜，菜谱上的“切丝”“焯水”“爆香”是动作，但真正决定一道菜成不成的是你对食材的了解：土豆容易氧化、牛肉要逆纹切、海鲜火候大了就老。数据库里的核心对象就是这些“食材”。
那么SQL里到底有哪些核心对象？我习惯把它们分成四类：
- 存储类：表（Table）、字段（Column）、约束（Constraint），负责数据到底放哪、怎么放。
- 查询映射类：视图（View）、索引（Index）、分区（Partition），负责数据怎么被快速找到、怎么被优雅呈现。
- 逻辑封装类：存储过程（Stored Procedure）、函数（Function）、触发器（Trigger）、游标（Cursor），负责业务流程怎么在数据库内部完成。
- 元数据与辅助类：序列（Sequence）、同义词（Synonym）、用户权限（User/Permission），负责数据之间怎么协作、谁有资格动数据。
这四个分类几乎覆盖了SQL Server、MySQL、Oracle、达梦这些主流关系型数据库的绝大部分日常操作。把它们的职责边界理清了，后面写任何SQL心里都有底。
1.2 一张表背后的设计学问：从字段类型说起
先说最基础的“表”对象。很多人建表很随意，字段类型大概差不多就往上一扔，结果上了生产环境才发现要么数据存不进去，要么查询慢得想骂人。字段类型这东西，看着小，实际坑特别多。
以整数类型为例，MySQL里有TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，SQL Server里有TINYINT、SMALLINT、INT、BIGINT，Oracle里直接是NUMBER(p,s)。我见过有人在MySQL里用一个INT(11)存性别字段，一个BIGINT存年龄，这种写法不是不行，但纯属浪费空间。一个表几百万行，多出来的每一字节都在膨胀你的索引、增加你的I/O开销。
时间字段更是个重灾区。有人喜欢用VARCHAR存日期时间，图省事，结果一到要按月份汇总、做时间范围查询的时候就傻眼了。VARCHAR类型的时间做比较是字符串比较，根本走不上索引优化，性能直接拉胯。正确的做法是：MySQL用DATETIME或TIMESTAMP，SQL Server用DATETIME2，Oracle用DATE。记住一个原则——能用原生时间类型就不要用字符串代替，省下的不仅是存储空间，更是后面的性能债。
还有一个容易忽略的字段设计点：字段语义要单一。一个字段只表达一个含义，别把一堆信息用逗号拼在一个字段里。很多人图省事，把标签用“1,2,5,8”存到一个字段里，等真的要做统计的时候才知道什么叫痛不欲生。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 视图：让复杂查询变简单的利器
2.1 视图的本质：一张“假表”的真实价值
视图在SQL核心对象里的地位很微妙。它不占物理存储空间（普通视图），本质只是一个“保存的查询语句”。但你别小看这个保存的动作——它能把一段动辄十几行、join了五六个表的复杂查询，封装成一个看起来像表的东西，后续所有应用只需要SELECT * FROM v_order_summary就行。
我最喜欢用视图解决的场景有两个：
第一个是权限隔离。比如一张员工表里有工资、身份证号这类敏感字段，如果直接把表给开发人员查询，等于把秘密都暴露了。这时创建一个视图，只暴露姓名、部门、入职日期这些非敏感字段，让应用只查视图，安全性和灵活度都保住了。
第二个是口径统一。公司里报表组、运营组、财务组都要统计数据，如果每个人各写各的SQL，出来的数字经常对不上。把核心指标口径做成视图，所有人查同一张视图，数据口径自然就统一了。
使用视图的时候有个容易踩的坑：视图上的排序是不稳定的。有些开发者在视图里写ORDER BY，以为数据查出来就有序，结果上线后发现页面排序时好时坏。原因很简单——视图本质是查询语句，外部查询再包一层时，优化器可能直接忽略内部排序。所以视图里排序只作为参考，真正的排序应该在外部查询显式指定。
2.2 物化视图：Oracle和PostgreSQL的隐藏大招
普通视图不占空间，但每次查询都要重新跑一遍底层SQL，如果基础表数据量特别大、而且查询频繁，性能就不太乐观了。这时候“物化视图”就登场了。
物化视图和普通视图最大区别在于：它会真的把查询结果存成一份物理数据。你查物化视图时，不是在执行底层的join和聚合，而是在读一份事先准备好的结果集，速度自然快得飞起。Oracle里可以用REFRESH COMPLETE或REFRESH FAST定期刷新，PostgreSQL支持REFRESH MATERIALIZED VIEW手动刷新。
MySQL本身没有内置物化视图，但很多场景可以用“定时任务 + 汇总表”来模拟。我之前做报表模块时，就是用Event Scheduler每小时跑一次汇总逻辑，把结果写进一张统计表，应用查询走这张表，效果和物化视图一模一样。
不过物化视图也有代价——它是“快照”数据，时效性会延迟；刷新的时候如果数据量大，还会消耗系统资源。所以它适合读多写少、时效要求不高的场景，比如日报表、周报表、BI看板。
3. 索引：查询加速背后的一整套逻辑
3.1 聚簇索引与非聚簇索引：选错主键，后面全是坑
索引大概是所有核心对象里最被关注、也最容易讲成玄学的东西。我用一个生活化的比喻来解释：一本字典，聚簇索引就是拼音目录，正文本身按拼音排序；非聚簇索引就是偏旁部首目录，它带着你找到某个字所在的页码，但正文并不按偏旁部首排列。
在MySQL InnoDB里，聚簇索引就是主键索引，表数据物理存储顺序由主键决定。这就是为什么我一直强调：主键尽量设置成自增整型，不要用随机UUID。因为UUID是随机分布，插入的时候可能导致页分裂、索引碎片化，写入性能会明显下降。而自增主键插入永远是追加式，顺序写磁盘，性能最稳。
SQL Server里聚簇索引可以在非主键列上创建，但建议还是跟着主键走。创建聚簇索引时选择字段要遵循原则：唯一、稳定、单调递增。用业务字段（比如身份证号、手机号）做主键不是不行，但一旦业务规则变了要改主键，代价可是伤筋动骨的。
非聚簇索引相当于“旁路索引”，它存的是索引列的值和对应行的主键。查询时先走索引找到主键，再回表取其他字段，这就是所谓的“回表查询”。如果索引列本身就覆盖了你要查的全部字段，那就不需要回表，这叫“覆盖索引”，是性能优化里性价比最高的招数之一。
3.2 复合索引的最左前缀原则：你真的会用吗
复合索引（也叫联合索引）是最容易被用错的索引类型。假设你建了一个联合索引(a, b, c)，数据库并不是说你这个索引对a、b、c的所有组合都生效，而是遵循“最左前缀”规则——只有当查询条件里有a时，索引才可能被用到；条件里没有a，只有b、c，这个索引大概率废了。
很多开发人员建索引时凭感觉，看到where条件有什么字段就往索引里塞，结果建了索引却没效果。我倾向于这样思考：先统计业务的常用查询模式，把经常一起出现的过滤字段放在一起，区分度大的字段放在最左边。
举个例子，订单表里经常按shop_id + order_date + status查询，那联合索引的顺序就按这个排。如果某个查询只按status过滤，这个联合索引帮不上忙，就单独为status建一个索引。这里同样要权衡——索引不是越多越好，每个索引都要占空间、都会拖慢写入速度。
还有一类非常典型的索引失效场景：在索引列上用函数或计算。比如WHERE YEAR(create_time) = 2024，就算create_time上有索引也用不上，因为每行都得先计算YEAR才知道匹配不匹配。正确写应该是WHERE create_time >= '2024-01-01' AND create_time < '2025-01-01'，既能走索引，语义也更准确。
3.3 索引失效自查：生产环境慢查询排查的关键点
我在公司里排查慢SQL时，基本有一套固定的checklist，按照这个顺序捋下来，90%的索引问题都能暴露出来：
- 用
EXPLAIN看执行计划，确认key列是否真的用到了预期索引。 - 检查
type列，从好到坏依次是const、eq_ref、ref、range、index、ALL，看到ALL基本意味着全表扫描。 - 看
rows列估算扫描行数，如果扫描行数和实际返回行数差距巨大，说明过滤性不好。 - 确认有没有在索引列上做隐式类型转换，比如字段是VARCHAR，查询条件却传了数值。
- 检查是不是用了
LIKE '%xxx'这种前置模糊匹配，这种写法索引基本无法利用。 - 留意
OR条件，如果OR连接的字段不是都有独立索引，优化器可能放弃索引走全表。
这些点看着不多，但每一条背后都藏着真实的翻车现场。我自己就曾经被一个隐式类型转换坑过：表里某字段是VARCHAR类型，查询条件写WHERE phone = 13800138000，phone列上的索引死活不走，后来才发现是字符串和数字比较导致索引失效，加上引号之后问题秒解。
4. 存储过程与函数：封装的边界与取舍
4.1 存储过程：到底该不该用
关于存储过程的争论，这些年一直没停过。支持的人说它性能好、网络开销小、逻辑内聚；反对的人说它难调试、难版本管理、绑死数据库。我的态度是——看场景，不做一刀切。
如果有复杂的多步骤事务处理、需要保证多条SQL要么全部成功要么全部回滚，用存储过程封装确实有优势。我做过一个库存扣减+订单生成+流水记录的业务逻辑，如果用程序代码在应用层实现，要处理分布式事务问题，复杂度极高；换成存储过程在一个数据库连接里用事务包裹，数据一致性有保障，出问题还好排查。
但如果你只是做一个简单的增删改查，完全没必要上存储过程。尤其是微服务架构下，每个服务独立部署、独立数据库，存储过程的跨库操作能力反而成了负担。我的建议是：存储过程适合做“重逻辑、高一致性”的数据库操作，不适合做“轻量级CRUD”。
使用存储过程还有一个很多人忽略的点——权限管理。只给应用账号存储过程的EXECUTE权限，不给底层表权限，能在一定程度上防止SQL注入攻击。因为应用能调用的只有被定义好的过程，而不是任意表数据。
4.2 函数：标量函数与表值函数的坑
SQL里的函数分两大类：标量函数（返回单值）和表值函数（返回一张表）。标量函数用起来很顺手，但性能隐患不小——它每处理一行都会执行一次，在百万数据上调用自定义标量函数，查询性能可能陷入泥潭。
我调过一个线上问题：某个报表查询加了两个自定义标量函数，数据量30万行，查询跑了快两分钟。后来把函数逻辑改写为JOIN关联，性能直接降到3秒。这中间的差别就在于：SQL是集合思维，函数是过程思维，用过程思维去处理集合数据，数据库优化器想帮你都帮不上。
表值函数相对好用一些，尤其是内联表值函数，它类似于“带参数的视图”，返回的是一个可查询的结果集。比如我要按月查询某订单数据的汇总，可以创建一个接收月份参数的函数，外部查询FROM dbo.fn_order_summary('2025-03')，逻辑清晰、复用性高，而且和JOIN配合时优化器还能做下推优化。
4.3 动态SQL：灵活背后的两个安全红线
提到存储过程，就绕不开动态SQL。动态SQL就是通过字符串拼接的方式去构建并执行SQL语句，它在处理“搜索条件不确定”的场景时非常便利。比如后台列表页有多个可选筛选条件，哪个有值就拼哪个进WHERE，用动态SQL最灵活。
但动态SQL有两个必须守住的安全红线。第一个就是SQL注入。如果拼接的内容里有用户直接输入的值，攻击者可以传入恶意代码让数据库执行。我在项目里要求团队所有动态SQL一律使用参数化方式，比如SQL Server的sp_executesql配合参数，MySQL的PREPARE/EXECUTE USING，或者MyBatis里的#{}占位符。
第二个红线和SQL注入原理类似，也是用户输入拼接进了表名、字段名等非参数化位置。比如排序字段由前端传，ORDER BY {column}，攻击者传入1; DROP TABLE xxx--，后果不堪设想。对这类非参数化位置，唯一稳妥的做法是白名单校验——前端传的值必须在一个预先枚举好的字段列表里，不在列表里就拒绝执行。
5. 触发器与事务：数据的守护与反噬
5.1 触发器：用之前必须想清楚的代价
触发器是SQL核心对象里最“阴险”的一个——它会在表发生INSERT/UPDATE/DELETE时自动执行你定义的一段SQL。很多人刚学会触发器的时候兴奋得不行，觉得自动化很酷，但实际开发里我建议尽量少用触发器，理由很简单：隐式逻辑是最难排查的故障源。
想象一下这个场景：某天线上数据错乱了，DBA开始排查，查了应用日志没发现问题，查了存储过程也没问题，最后折腾两个小时才发现某个表上挂了一个触发器，在UPDATE时悄悄改了另一张表的数据。这种问题定位成本极高，而且触发器里的逻辑出了错，往往会把错误传导到很远的脏数据里。
当然，触发器也不是全无用处。比如审计日志场景——要求对某张核心表的任何变更都留痕，如果靠应用端统一封装，总会有漏网之鱼。用触发器在数据库层面强制记录变更，数据一致性就有保障。我在一些金融项目里见过这种做法，效果确实可靠。
如果决定使用触发器，注意几个细节：
- 触发器内部必须处理异常，不能让主表操作因为触发器出错而失败。
- 严格限制触发器的递归调用和嵌套调用，防止死循环。
- 在高并发写入的表上慎用触发器，因为触发器本身会延长写事务的锁持有时间。
5.2 事务隔离级别：并发与一致性的天平
事务是保证数据一致性的核心机制，ACID四个属性学校里都教过，但实际生产环境中真正容易出问题的是事务的隔离级别。SQL标准定义了四种隔离级别，由低到高分别是：READ UNCOMMITTED（读未提交）、READ COMMITTED（读已提交）、REPEATABLE READ（可重复读）、SERIALIZABLE（串行化）。
每种隔离级别解决了一部分问题，但也会带来新问题。直接从理论说可能不好记，我用一个存款场景来说：你的账户有1000块，与此同时，另一笔转账正在给它加500块。
- 在READ UNCOMMITTED级别下，你可能会查到别人还没提交的1500块，然后这笔事务又回滚了，你查到的数据就是脏数据，这叫脏读。
- 在READ COMMITTED级别下，脏读被解决了，但你可能在一个事务里两次查询同一条记录，得到不同结果（第一次1000，第二次1500），这叫不可重复读。
- 在REPEATABLE READ级别下，同一事务内多次读取结果一致，但可能出现幻读——你查订单总数是100条，另一会话插入了新订单并提交，你再查就变成101条了。
- 在SERIALIZABLE级别下，所有问题都解决了，但并发性能也基本没了，因为涉及范围的行都被锁住了。
MySQL的InnoDB默认是REPEATABLE READ，但通过MVCC（多版本并发控制）基本解决了幻读问题；SQL Server默认是READ COMMITTED；Oracle默认是READ COMMITTED。了解你正在用的数据库的默认行为很重要，因为它直接决定你的业务逻辑在高并发下会不会出现数据错乱。
5.3 死锁的产生与化解：程序员必会的保命技巧
死锁是并发环境下绕不开的话题。它的本质是两个或多个事务互相持有对方需要的锁，谁也不让谁，最终数据库选一个牺牲者回滚，释放锁让另一个跑通。
我遇到过的死锁经典场景是：两个事务都走了“先更新A表再更新B表”的路径，但A、B的顺序刚好相反。比如事务1先锁A再锁B，事务2先锁B再锁A，两边互相等待，就死锁了。
化解死锁有几个经验法则，我做了这么多年数据工作，基本每次都能靠这几招脱身：
- 统一加锁顺序：所有事务都严格按同一顺序更新表，比如先A后B，绝不反向。
- 事务尽量短：把事务里无关的查询挪到事务外面，减少锁占用的时间。
- 合理使用索引：更新条件走索引，可以让锁定的行范围尽量小，而不是锁住整张表。
- 设置锁超时时间：MySQL的
innodb_lock_wait_timeout默认50秒，可以根据业务合理调低。
6. 游标：最后的手段，也是必要的存在
6.1 什么时候该用游标
游标在SQL核心对象里是个异类——它是面向过程的，与SQL“集合操作”的天然理念相悖。每次使用游标，意味着你要一行一行地循环处理数据，性能远不如一次性的集合操作。所以我的第一条建议永远是：能用集合查询解决的，绝对不要上循环。
但有些场景确实非用游标不可。比如要对某张表的每一行做一次复杂的逻辑判断后再决定怎么更新另一张表，如果用一条UPDATE解决不了，就得用游标逐行处理。这时候游标虽然繁琐，却能把逻辑写清楚、可控性好。
用游标要注意性能优化技巧：优先使用LOCAL FAST_FORWARD类型的游标，这种游标是只进、只读的，性能比默认动态游标高一截；游标循环结束后务必关闭并释放，否则连接资源会被占用很久。
6.2 游标的替代方案：用窗口函数实现“行间运算”
老实说，这些年我在实际业务里用游标的频率已经大幅下降，因为我发现很多原来被迫用游标才能实现的“行间计算”，完全可以用SQL的窗口函数搞定。比如计算每行和上一行的差值、求移动平均值、按组内排名——这些在SQL Server和PostgreSQL等主流数据库里都有成熟的窗函数支持。
窗口函数里最常用的是ROW_NUMBER()、RANK()、DENSE_RANK()、LAG()、LEAD()、SUM() OVER(PARTITION BY ... ORDER BY ...)。它们能在一次扫描里完成分组、排序、聚合等操作，性能远超逐行循环。
举个例子：我要按用户分组，找出每个用户最近一笔订单。最笨的做法是查所有订单到应用层循环分组，游标方法是一行行遍历、比对，而窗口函数只需要一句话：
sql复制SELECT user_id, order_id, order_date
FROM (
SELECT user_id, order_id, order_date,
ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_date DESC) AS rn
FROM orders
) t
WHERE rn = 1;
这条语句让数据库一次扫描完成分组排序，效率比游标高一个量级。遇到行间运算时，先想想窗口函数能不能解决，能解决就不要碰游标。
6.3 游标的正确打开方式：写之前先画流程图
如果实在绕不开游标，我会先画一张流程图，理清楚每一行处理时涉及哪些表的读写，避免在循环里做“不该做的事”。
常见的游标性能杀手是“循环里逐条执行SELECT/UPDATE”，比如游标每取一行就去另一张表查询一次，结果就是循环N次就产生N次查询，性能隐患很大。优化思路是先把外部表数据一次性读入临时表，游标循环里只做内存判断和批量更新。
还有一点，务必给游标加上READ ONLY和FAST_FORWARD选项，明确告诉数据库“我只读、只前进”，这样数据库可以采用更高效的执行策略。千万不要习惯性地用默认的动态游标，那意味着数据库要维护完整的可更新、可滚动的游标状态，开销是前者的数倍。
7. 技术选型与排查实战：从一行慢SQL到全链路优化
7.1 EXPLAIN执行计划：把SQL的底裤扒开看
学习SQL核心对象，最终目的还是写出高性能的查询。而查看性能最直接的工具就是EXPLAIN。不管是MySQL还是SQL Server，都有执行计划功能，你要做的是养成写完复杂SQL就跑一遍执行计划的习惯。
MySQL的EXPLAIN输出里，重点关注这些列：
id：查询编号，id越大越先执行。select_type：查询类型，比如SUBQUERY、DERIVED、UNION等。table：访问的表，可能是真实的表，也可能是衍生表。type：访问类型，从高到低是system、const、eq_ref、ref、range、index、ALL。possible_keys：可能用到的索引。key：实际使用的索引。rows：预估扫描的行数。Extra：额外信息，比如Using index就是覆盖索引，Using filesort就是文件排序，要特别注意。
我曾经接手过一个查询接口，线上响应要3秒多。用EXPLAIN一看，type=ALL，全表扫描了几百万行，还有Using filesort。后来建了符合查询条件的联合索引，让排序字段也进入索引，响应直接降到200毫秒以内。这个案例里，索引设计+查询改写缺一不可。
7.2 SQL语句去重的几种写法：DISTINCT还是GROUP BY
去重查询在开发中非常常见，热搜词里也有“sql语句去重查询”和“清洗---sql语句去重”。去重最常见的写法是SELECT DISTINCT col1, col2 FROM table，这写法简洁直观，但它会对返回的全部列组合做去重，如果列很多、数据量很大，排序去重的开销不可小觑。
另一种常用的去重方案是GROUP BY：
sql复制SELECT user_id, MAX(create_time) AS latest_time
FROM orders
GROUP BY user_id;
GROUP BY的意义更多在于“每个分组取什么值”，配合聚合函数可以玩出很多花样。比如留存分析里要取每个用户的首单时间、末次访问时间，DISTINCT就无法做，而GROUP BY + MIN/MAX就是标准解法。
还有一种更精确的行级去重，使用窗口函数：
sql复制SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY create_time DESC) AS rn
FROM orders
) t
WHERE rn = 1;
这可以保留每组里最新一条完整记录，是清洗数据时的高频操作。总结一下：简单去重用DISTINCT，分组聚合用GROUP BY，保留最新一条完整记录用窗口函数，各司其职。
7.3 BETWEEN AND的边界问题、AND/OR的执行顺序
很多人在SQL语法上吃过亏的还有两个点：BETWEEN AND和AND/OR混合条件。
BETWEEN AND在大多数数据库里是包含边界值的，比如WHERE age BETWEEN 18 AND 30会包含18岁和30岁。但这里有一个坑：如果边界值是日期时间，比如BETWEEN '2025-01-01' AND '2025-01-31'，在MySQL里'2025-01-31'会被当作2025-01-31 00:00:00，也就是说1月31日当天后面的时间（比如08:00）根本不在范围内。这是写报表统计时最经典的bug之一。正确做法是写BETWEEN '2025-01-01' AND '2025-02-01'（右开区间），或者用>= AND <显式控制范围。
关于AND和OR的执行顺序，核心规则是：AND的优先级高于OR。也就是说WHERE a = 1 OR b = 1 AND c = 1会先执行b=1 AND c=1，再和a=1做OR。如果业务意图是“(a=1 OR b=1) AND c=1”，不写括号就会出错。我的经验是：只要SQL里同时出现AND和OR，一律给OR加上括号，不要靠记忆去赌优先级，这样既防止出错，代码可读性也好很多。
8. 数据库实操心得：我从故障中总结的三条铁律
8.1 上线前一定要做的三件事
这些年做数据库相关工作，我把“上线前检查”总结成三件必做的事：
第一件，用真实数据量做性能验证。开发环境只有几千条数据，随便怎么写都很快，但生产环境是几百万、几千万行，SQL执行计划可能完全不同。我见过太多案例，开发环境毫秒级，到了生产环境因为数据量级上来了，索引选择性变化，一条查询从毫秒变成几十秒。所以上线前至少要用生产同量级的脱敏数据做一轮压测。
第二件，检查索引设计是否覆盖核心查询。统计业务里面最高频的10条查询，逐一用EXPLAIN确认执行计划，确保没有全表扫描、没有排序落盘。这10条查询的性能基本决定了系统的整体体验。
第三件，列好回滚方案。数据库结构变更（比如加索引、改字段类型）有时候会引发意想不到的问题，比如锁表导致业务不可用。操作前必须想清楚：这个变更要不要锁表？怎么锁？锁多久？如果出了线上事故，怎么快速回滚到旧结构？
8.2 参数化查询与SQL注入防护的真相
SQL注入一直是数据库安全里最经典、也最严重的话题。热搜词里“sql注入万能密码绕过”就在说这个问题。所谓万能密码绕过，本质就是利用拼接SQL时对输入值不加过滤，让攻击者在密码字段里输入' OR '1'='1，把WHERE条件永远置真，从而绕过身份验证。
防护手段首推参数化查询。在Java的JDBC里用PreparedStatement，在MyBatis里用#{}，在Python的pymysql里用%s占位符，在SQL Server里用sp_executesql参数方式。参数化查询的意义在于：用户输入永远被当作“值”处理，而不是被拼进“SQL结构”里，即使里面写了SQL片段，数据库也只把它当普通字符串。
我自己处理过很多安全扫描出来的SQL注入漏洞，修复方案几乎都是把字符串拼接改成参数化查询。唯一例外的是ORDER BY、表名这类没法参数化的部分，只能靠白名单过滤。
8.3 如何维护一份高质量的核心SQL知识库
最后分享一个我自己的习惯：维护一份SQL核心对象的“踩坑知识库”。只要在开发或运维中踩到一个坑，解决后我就把它记下来，格式很简单——问题现象、产生原因、根因原理、解决方案、预防措施，五个要素。
比如记录“BETWEEN AND日期边界”这条，我一定会在解决方案里写上正确的边界写法，还会附一个小例子。积累一段时间后，这份知识库就成了团队新人的“避坑指南”，遇到问题先翻一遍，大部分坑都能避开。这种方式比零散地记笔记高效得多，因为你记录的每一个坑都是真实发生过的，有上下文、有解决方案，是可以直接复用的经验。
对于正在学习SQL核心对象的朋友，我的建议是一样的：不要追求把所有语法背下来，更重要的是理解每个对象的设计意图和适用边界，然后在真实业务场景里反复使用、反复踩坑、反复总结。数据库这块，你踩过多少次坑，就能进步多少。