企业官网建设流程全解析

做ABAP开发，SE11里点下激活只是几秒钟，真正决定报表命运的是索引有没有建对。ABAP索引的生成与使用，表面看是数据字典里加几个字段，背后其实是DDIC、数据库优化器、Open SQL写法和传输链路一起配合。很多人第一次听到索引，会想到MySQL的CREATE INDEX、Oracle的ALTER INDEX，或者Lucene的倒排索引、pandas的标签切片；在ABAP世界里，这些东西不是一回事。ABAP不让你在Open SQL里随手指定索引，也不建议直接到数据库层改对象，而是通过透明表、数据字典和SE11把索引定义交给数据库层生成。这篇文章我按一线开发的视角，把ABAP索引从创建、激活、传输，到Open SQL命中、ST05验证、DB02监控，再到常见坑和完整案例一次讲透。适合刚接触ABAP数据字典的新人，也适合被慢报表折磨过的顾问和运维。

1. ABAP索引到底是什么：先搞清主键索引和二级索引

1.1 索引不是ABAP独有，但ABAP有自己的生成方式

数据库索引本质上是一种用额外空间换查询速度的数据结构。传统行式数据库里，最常见的是B树或B+树索引，它把索引字段按顺序组织起来，查询时先走索引定位，再回表取完整记录。列式数据库比如SAP HANA，物理组织和行式数据库差别很大，列存、字典编码、扫描优化会改变索引的收益模型。所以讨论ABAP索引时，不能只背“建索引就快”这句话，得先看底层数据库是什么形态。

ABAP层面对索引的管控，主要通过数据字典DDIC完成。透明表在SE11里定义，激活时数据库层会生成对应表，主键自动生成唯一索引。二级索引也在SE11里维护，保存激活后由DDIC生成数据库DDL，落到实际数据库对象上。池表和簇表是特殊情况，它们不是一对一透明表，通常不能像透明表那样自由创建二级索引。很多新人上来就想给所有表加索引，结果忽略了表类型，最后激活报错或者根本达不到预期。

ABAP不鼓励开发者在Open SQL里写数据库Hint，也不建议直接登录数据库执行CREATE INDEX。原因很现实：SAP系统要跨数据库平台运行，今天跑在HANA，明天可能跑在别的数据库上；绕过DDIC直接建索引，传输链路、升级、备份恢复都会出现不一致。ABAP索引的“生成”不是写一条SQL，而是在SE11里定义对象，让系统去生成。这个边界必须清楚。

1.2 主键索引和二级索引的分工与代价

主键索引是透明表自带的。你在SE11里定义主键字段，激活表时数据库层就会生成主键约束和对应唯一索引。对于客户端相关表，MANDT通常是主键第一位，数据库主键索引自然包含客户端。主键索引负责唯一性，也负责按主键访问的效率。比如按VBELN读取VBAK、按MATNR读取MARA，主键或标准索引通常已经能覆盖，不一定需要你再动手加二级索引。

二级索引是业务查询逼出来的。比如自建表ZLOG_GEN，主键是MANDT加LOG_ID，但程序天天按USER_NAME、LOG_DATE、STATUS组合查询。主键索引用不上，数据库只能全表扫描。这时二级索引才有意义。二级索引可以唯一，也可以非唯一。唯一索引除了加速，还承担数据校验职责；非唯一索引只加速查询。代价也很直接：每次INSERT、UPDATE、DELETE，数据库都要同步维护索引，索引越多，写入越慢，占用的存储也越大。

我经常用一个生活类比解释：主键索引像图书馆按书号排架，二级索引像按作者、按分类另做一套卡片。卡片能让你快速找到某作者的书，但每进一本新书，管理员就得多写几张卡片。如果某个作者只有一本书，卡片可能永远用不上，反而增加维护成本。ABAP索引设计也是这个道理：不是越多越好，而是看查询模式、字段选择性和写入频率。

1.3 什么场景该建索引：从慢报表反推

判断要不要建索引，最靠谱的方法是先看慢在哪里。打开ST05录一段SQL trace，看程序到底发了哪些SELECT，哪些表被全表扫描，WHERE条件用了什么字段，返回多少行。如果一条查询每次只取几行，却要扫几百万行，那大概率需要索引。如果一条查询本身就要取全表数据，比如无条件汇总整张表，索引也救不了，应该考虑聚合表、CDS视图、后台Job预计算或者分区。

字段选择性是第二个判断标准。选择性高，意思是字段值重复度低，比如订单号、物料凭证号、日志ID；选择性低，意思是字段值重复度高，比如状态、删除标记、公司代码。一个只有三种值的STATUS字段单独建索引，优化器很可能不选，因为走索引再回表还不如直接全表扫描。组合索引里，高选择性字段通常放前面，等值查询字段放前面，范围查询字段放后面，这个顺序会直接影响命中效果。

第三是写入比例。日志表、接口表、CDS抽取表通常写入频繁，索引多了会拖慢写入。交易表写入少、查询多，可以适当多建。我的习惯是：先根据核心查询建一到两个组合索引，上线后用DB02和ST05观察，再决定是否补索引。不要一开始就按“每个字段都来一个”的思路铺开，那种表到后面维护起来很痛苦。

2. 在SE11里生成索引：从字段选择到激活的完整操作

2.1 创建索引的详细步骤与参数怎么填

SE11创建索引的入口不复杂。输入透明表名，点击显示，进入表维护界面后找到“索引”相关按钮或菜单，进入索引列表。点击创建，输入索引名。客户自定义对象一般用Z或Y开头，比如Z01、Z02。描述写清楚用途，比如“按用户和日期查询日志”。然后选择索引字段。对于客户端相关表，MANDT会自动出现在索引字段第一位，通常不需要你手动选，也删不掉。选完字段后决定是否勾选唯一。保存时会要求传输请求，激活后数据库层生成索引。

这里有个细节：索引名不是随便无限长，底层数据库对索引名长度有限制，SAP会做转换。你看到的名字可能是ZLOG_GEN~Z01，数据库层可能还有自己的命名规则。所以不要用特别长、特别随意的索引名。描述字段要写人话，因为半年后你或者同事再来看，只有描述能快速说明这个索引是干什么的。索引字段选择界面里，字段顺序就是最终数据库索引的列顺序，顺序错了，后面查询可能完全用不上。

创建前还要确认表类型。透明表可以建二级索引，池表和簇表通常不行。标准表要格外谨慎，SAP标准表属于SAP命名空间，直接改可能影响升级和一致性。确实需要给标准表加索引时，一般要走SAP Note、对象注册或者SAP支持渠道，不能像自建表那样随手加。开发机改完还要通过传输请求进测试机和生产机，生产系统不能直接动DDIC。

2.2 字段顺序、唯一性和MANDT的坑

字段顺序是二级索引最容易踩的坑。组合索引遵循最左前缀原则：查询条件必须从索引第一列开始连续匹配，才能有效利用。比如索引是USER_NAME、LOG_DATE、STATUS，那么WHERE USER_NAME = ?能用，WHERE USER_NAME = ? AND LOG_DATE = ?能用，WHERE LOG_DATE = ?单独用通常用不上这个索引。如果业务里既有按用户查，也有按日期查，可能要考虑两个索引，或者调整索引字段顺序。

等值条件、范围条件、排序字段的顺序也要考虑。通常把等值条件字段放前面，范围条件字段放后面。因为一旦遇到范围查询，后面的索引列可能无法继续用于精确定位。比如WHERE USER_NAME = ? AND LOG_DATE BETWEEN ? AND ? AND STATUS = ?，索引USER_NAME、LOG_DATE、STATUS在传统B树里，STATUS可能只能作为过滤条件，不能像等值那样精确定位。如果把STATUS放LOG_DATE前面，STATUS等值先过滤，再在范围内找LOG_DATE，可能更合适。实际选哪种，要看数据分布和ST05结果。

MANDT的坑主要出现在客户端相关表。系统自动把MANDT放第一位，所以你的索引天然带客户端隔离。Open SQL里虽然经常不写MANDT，但SAP会自动加客户端条件。不要试图把MANDT放到后面或者去掉，系统不允许，也没必要。唯一索引还要注意：如果表里已有重复数据，激活唯一索引会失败。上线前要先跑重复检查，确认业务上真的唯一。唯一索引一旦建立，后续写入如果违反唯一性，程序必须处理sy-subrc或异常，不能假设永远不冲突。

2.3 激活与传输背后的数据库动作

保存索引只是DDIC层记录，激活才是真正生成数据库对象。激活时系统会向底层数据库发送DDL。对于小表，这个过程很快；对于几千万行的大表，建索引可能持续几分钟甚至更久，期间可能占用较多数据库资源。传统数据库里还可能锁表，影响业务写入。所以大表加索引要安排在维护窗口，或者至少避开业务高峰。HANA的在线DDL能力强一些，但也不能完全不做评估。

传输链路也要重视。索引属于DDIC对象，通常跟随表的传输请求走。开发机创建、激活、测试机导入、生产机导入，每一步都要确认激活成功。我见过开发机测试没问题，生产导入后索引没激活，程序继续慢，排查半天才发现是传输里少了对象或者激活报错被忽略。生产导入后可以用DB02看索引状态，也可以用ST05跑一次核心查询确认执行计划变了。不要只看SE11里索引存在，就认为数据库层一定生效。

另外，索引创建后不是一劳永逸。数据库统计信息、碎片、数据分布变化都会影响优化器选择。传统数据库可能需要定期更新统计信息、重建碎片严重的索引；HANA列存下机制不同，不能照搬。SAP系统里一般通过DB02、DBACOCKPIT等标准工具监控，不建议直接登录数据库执行维护命令。所有动作尽量走SAP标准路径，保证DDIC和数据库层一致。

3. 让Open SQL命中索引：写法、执行计划与性能验证

3.1 Open SQL里哪些写法会让索引白建

索引建好只是第一步，Open SQL写法不对，索引照样用不上。最常见的是在WHERE条件里对字段做函数、计算或类型转换。比如WHERE SUBSTRING(LOG_DATE, 1, 4) = '2024'，数据库无法直接用LOG_DATE索引，因为列被函数包住了。再比如WHERE LEFT(USER_NAME, 2) = 'ZH'，同样失效。正确做法是让字段独立出现在比较符左边，把计算放到变量或程序侧。

前导通配符也是经典问题。LIKE '%ABC'不能让B树索引做范围定位，只能扫描；LIKE 'ABC%'才可能利用索引。OR条件、NOT条件、IS NULL、IS NOT NULL也可能让优化器放弃索引，具体看数据库和统计信息。字段类型不匹配、隐式转换、前导零处理不当，也会让索引失效。比如物料号、客户号在DDIC里有转换例程，如果内表变量类型选错，Open SQL生成的条件可能和索引列类型不一致，数据库要做转换，索引就用不顺畅。

FOR ALL ENTRIES也要小心。它会根据内表生成一组条件，内表为空时结果不可控，内表有重复值会影响效率。驱动表的选择、内表排序和去重、条件字段是否有索引，都会影响执行计划。它不是不能用，而是不能无脑用。尤其是大内表驱动大表查询时，可能生成大量OR条件，反而不如先落临时表再关联。现代ABAP里可以考虑CDS视图、JOIN、AMDP，但底层表索引依然重要。

3.2 用ST05和DB02看索引到底有没有被用

ST05是ABAP开发最常用的SQL跟踪工具。输入事务码ST05，选择SQL trace，激活跟踪，运行程序，停止跟踪，显示跟踪。你能看到每条SQL、执行时间、访问的表、WHERE条件，还能看执行计划。执行计划里重点看表访问方式：全表扫描、索引范围扫描、索引唯一扫描、rowid访问等。如果一条慢查询显示全表扫描，而WHERE字段正好是你建索引的字段，就要检查索引是否激活、字段顺序是否匹配、条件是否被函数包住。

DB02更偏数据库层面，可以看表大小、索引大小、索引字段、状态、碎片、统计信息。开发人员不需要成为DBA，但至少要会看几个关键信息：索引是否存在、是否有效、字段顺序是什么、最后一次统计信息更新时间。SQLM和SQL Monitor可以帮你从系统整体角度发现高频慢SQL，尤其适合生产系统。HANA系统里还可以结合HANA执行计划和计划分析，看列扫描、过滤、聚合的耗时分布，不能只用传统B树思维判断。

我通常的验证顺序是：先在开发或测试系统用ST05复现慢查询，确认问题表和WHERE字段；再在SE11检查索引是否存在、字段顺序是否匹配；然后在DB02确认数据库层索引有效；最后回ST05看执行计划是否变化。如果索引存在但没被选，先看统计信息和数据分布，再看SQL写法，最后才考虑调整索引。直接删了重建往往不是第一步。

3.3 索引失效的常见触发条件速查表

下面这张表是我自己排查时常用的速查表，场景、原因和改写思路放在一起，方便对着ST05结果逐条排除。

这张表不是绝对规则，不同数据库、不同版本、不同数据分布都会影响优化器。它的价值在于给你一个排查顺序，而不是让你背下来当法律条文。遇到慢查询，先ST05，再对照表，再决定是改SQL、改索引还是改数据模型。

4. 维护、监控与避坑：索引不是建完就完事

4.1 索引的日常监控与重建删除策略

索引上线后要有人管。DB02里可以看索引大小和增长趋势，如果某个索引占了几百GB却很少被使用，就要评估是否值得保留。传统数据库里，索引碎片严重会影响性能，可能需要重建；统计信息过期会导致优化器选错执行计划，需要更新统计信息。HANA列存下这些概念有变化，更多依赖列扫描、字典和计划缓存，不能直接套用行式数据库的维护脚本。SAP系统里优先使用DB02、DBACOCKPIT等标准工具，避免手工执行数据库命令。

删除索引比创建索引更危险。创建错了最多浪费空间和写入性能，删除错了可能让核心报表直接全表扫描。删除前要确认：有没有程序依赖这个索引、有没有SQL执行计划正在使用、是不是SAP标准索引、有没有传输请求关联。标准表上的SAP索引尤其不能乱动，那可能是SAP标准程序性能的保障。客户自定义索引也要先在测试系统用ST05验证删除后的影响，再考虑生产删除。我的习惯是：先设为待观察，记录使用情况，过一段时间再决定。

重建索引也不是万能药。有些性能问题来自SQL写法、数据量增长、表设计不合理，重建索引只能暂时缓解。比如一张日志表每月增长几千万行，查询永远按月份过滤，那更应该考虑分区、归档、汇总表，而不是反复重建索引。索引是优化手段之一，不是唯一手段。先定位瓶颈，再选工具。

4.2 自建表、标准表和CDS场景下的不同策略

自建表最自由。表结构、索引、传输都在自己控制范围内，可以按查询模式设计。我的建议是：自建表上线前就把核心查询列出来，至少建一个覆盖主查询的组合索引。不要等生产数据涨到几千万行才加索引，那时候激活和传输都更麻烦。自建表还要注意客户端字段、删除标记、时间戳字段的分布，别让低选择性字段占据索引前导位置。

标准表要谨慎。SAP标准表通常已有SAP预定义索引，开发前先用SE11看索引列表，很多时候标准索引已经覆盖了常见查询。确实不够时，先查SAP Note，看官方有没有推荐方案，再考虑对象注册和修改。直接给标准表加Z索引，可能在升级、支持包、数据库迁移时出问题。标准表查询优化还可以考虑CDS视图、SAP标准API、缓冲表、归档，不一定非要加二级索引。

CDS视图和AMDP是另一层。CDS视图本身不直接等同于DDIC二级索引，它定义的是语义模型和查询接口。底层表如果没有合适索引，CDS查询一样会慢。CDS的注解、关联、聚合、参数化会影响生成的SQL，最终还是要看数据库执行计划。AMDP里写原生SQL时，索引规则和普通数据库更接近，但跨数据库兼容性和SAP管控要求更高。无论哪层，索引都是底座，不能绕过。

4.3 我踩过的几个典型坑

第一个坑是字段顺序想当然。曾经给自建表建了索引LOG_DATE、USER_NAME、STATUS，结果程序主要按USER_NAME加日期查，最左前缀用不上，索引几乎白建。后来改成USER_NAME、LOG_DATE、STATUS，ST05里立刻从全表扫描变成索引范围扫描。这件事让我记住：索引字段顺序不是按表字段顺序排，而是按查询条件的使用频率和选择性排。

第二个坑是唯一索引导致写入失败。业务上以为某个字段唯一，上线后发现历史数据有重复，或者并发写入时重复，程序没处理sy-subrc，接口报错。唯一索引能保证数据质量，但前提是业务规则真的唯一，且程序有异常处理。建唯一索引前一定先跑重复数据检查，尤其是接口表、日志表、临时表，这些表的数据质量往往没交易表那么干净。

第三个坑是传输后生产没激活。开发机测试通过，生产导入时索引激活失败，可能因为生产数据有重复、表结构不一致、数据库资源不足。程序继续慢，大家以为是代码问题。后来养成习惯：生产导入后一定用DB02看索引状态，用ST05跑核心查询确认执行计划。索引不是传到生产就自动生效，激活结果必须确认。

第四个坑是忽略表缓冲。有些表在SE11技术设置里开了缓冲，Open SQL访问时可能命中应用服务器缓冲，根本不走数据库索引。如果查询条件不满足缓冲键，又会绕过缓冲走数据库。索引和缓冲是两套机制，不能混为一谈。优化前先看表的技术设置，确认访问路径到底是缓冲还是数据库。

5. 一个完整案例：给自建日志表ZLOG_GEN建立并使用索引

5.1 需求与表结构

假设有一张自建日志表ZLOG_GEN，用来记录接口调用日志。字段包括MANDT、LOG_ID、USER_NAME、LOG_DATE、STATUS、MSG、CREATED_AT。主键是MANDT加LOG_ID，保证每条日志唯一。数据量每天新增几十万行，半年后表里有五千万行。业务最常用的查询是：按用户、日期范围、状态查日志列表。程序上线初期数据少，没感觉；数据涨起来后，报表打开要二十多秒，ST05显示ZLOG_GEN全表扫描。

这张表是客户端相关表，MANDT自动进索引第一位。查询条件里USER_NAME等值，LOG_DATE范围，STATUS等值。根据前面的原则，组合索引可以考虑USER_NAME、LOG_DATE、STATUS，MANDT由系统自动加在最前。为什么不是LOG_DATE、USER_NAME、STATUS？因为业务查询几乎都会带USER_NAME，USER_NAME选择性也比日期高一些，放前面更利于定位。STATUS只有几种值，放最后做过滤。这个顺序不是拍脑袋，是从实际SQL模式反推的。

建索引前还要评估写入。日志表写入频繁，每多一个索引都会增加INSERT成本。所以不能给USER_NAME、LOG_DATE、STATUS、MSG都单独建索引，只能建一个覆盖主查询的组合索引。如果后续还有按状态加日期的后台统计查询，再评估是否补第二个索引，或者用汇总表解决。索引设计要服务核心查询，不是服务所有可能查询。

5.2 创建与验证过程

在SE11打开ZLOG_GEN，进入索引列表，创建索引Z01，描述“按用户日期状态查日志”。字段选择USER_NAME、LOG_DATE、STATUS，MANDT自动排第一。不勾选唯一，因为同一用户同一天同一状态可能有多条日志。保存到传输请求，激活。激活后到DB02确认索引ZLOG_GEN~Z01存在且有效。然后回到ST05，重新录制原报表，对比执行计划。

程序里的Open SQL保持简单，让字段独立出现在条件左侧。现代ABAP写法可以这样：

DATA: lv_user TYPE zlog_gen-user_name, lv_from TYPE zlog_gen-log_date, lv_to TYPE zlog_gen-log_date, lv_status TYPE zlog_gen-status. SELECT log_id, user_name, log_date, status, msg FROM zlog_gen INTO TABLE @DATA(lt_log) WHERE user_name = @lv_user AND log_date BETWEEN @lv_from AND @lv_to AND status = @lv_status.

经典ABAP写法也能命中索引，关键不在语法新旧，而在条件写法：

SELECT * FROM zlog_gen INTO TABLE lt_log WHERE user_name = lv_user AND log_date BETWEEN lv_from AND lv_to AND status = lv_status.

注意不要写成WHERE substr( user_name, 1, 2 ) = 'ZH'，也不要在LOG_DATE上做年份截取。如果报表需要按月份汇总，可以在变量侧算好月初月末，再用BETWEEN。这样数据库才能用索引做范围扫描。ST05里如果看到INDEX RANGE SCAN或者类似索引访问方式，说明索引生效；如果还是TABLE ACCESS FULL，就要检查字段顺序、类型、数据分布和统计信息。

5.3 效果评估与后续优化

这个案例里，建索引后报表从二十多秒降到一秒以内，ST05显示从全表扫描变成索引范围扫描，返回行数也控制得比较好。写入方面，INSERT耗时略有增加，但日志写入不是高频交易，可以接受。DB02里索引大小随着数据增长，需要定期观察。如果日志表继续涨到几亿行，单靠二级索引可能不够，要考虑按月份分区、归档历史数据、把统计查询转到汇总表或CDS聚合视图。

后续如果出现只按LOG_DATE查询的场景，现有索引USER_NAME、LOG_DATE、STATUS可能用不上，因为跳过了USER_NAME前导列。这时不要急着再加一个索引，先看这种查询的频率和数据量。如果只是偶尔后台统计，可以接受全表扫描或者用Job跑；如果频率很高，再评估建LOG_DATE、STATUS索引，或者调整现有索引顺序。索引调整要基于ST05和DB02的数据，不是凭感觉。

还有一个容易忽略的点：日志表数据分布会随时间变化。早期数据少，优化器可能不选索引；数据涨起来后，统计信息没更新，优化器可能继续误判。传统数据库要关注统计信息更新，HANA列存下要看执行计划和计划缓存。无论哪种，索引上线后都要持续观察，不能建完就不管。

6. 进阶：ABAP索引与数据库优化器的协作

6.1 优化器为什么有时不选你的索引

索引存在不等于一定会被使用。数据库优化器会根据成本估算选择执行计划。如果它认为全表扫描成本更低，就会放弃索引。常见原因包括：表太小、索引选择性太低、统计信息过期、查询返回行数占比太高、索引字段被函数包住、类型隐式转换、OR条件太复杂。比如STATUS只有三种值，查其中一种可能返回三分之一数据，优化器觉得走索引再回表不如直接扫描。这不是索引没用，而是这个查询场景不适合它。

不同数据库的优化器行为不同。MySQL、Oracle、达梦、GBase等都有自己的成本模型和Hint机制，但ABAP层一般不直接写Hint。Oracle里DBA可以用ALTER INDEX UNUSABLE让索引不可用，用来对比性能，但在SAP生产系统里不能这么干，因为DDIC和数据库层会不一致，后续支持、升级、恢复都可能出问题。SAP系统里做索引对比，应该在测试系统通过SE11创建或删除候选索引，再用ST05和DB02验证。

HANA又是另一套逻辑。列存表本身对全表扫描和聚合有优化，字典编码、内存计算、并行执行会改变索引收益。DDIC二级索引在HANA里的物理表现和传统行式数据库不同，不能拿B树经验硬套。判断是否命中，要看HANA执行计划，看列扫描、过滤、聚合的耗时，而不是只盯着“有没有走索引”这个标签。索引在HANA里依然有意义，但设计思路要结合列存特点。

6.2 从ABAP层到数据库层的完整链路

ABAP索引的完整链路可以这样理解：开发者在SE11定义透明表和索引，DDIC保存元数据，激活时生成数据库表、主键约束和二级索引；ABAP程序通过Open SQL发查询，SAP内核把Open SQL转换成数据库SQL，数据库优化器选择执行计划，实际访问表或索引；ST05抓取SQL和执行计划，DB02查看数据库对象和统计信息。这个链路里任何一环出问题，都会表现为“索引没生效”。

传输是链路里的关键环节。开发机创建索引并激活，测试机导入并激活，生产机导入并激活。每一步都要确认激活成功。生产导入后如果索引激活失败，可能是数据重复、表结构差异、资源不足、权限问题。开发人员要养成检查习惯：SE11看索引定义，DB02看数据库状态，ST05看实际执行计划。三处一致，才叫真正上线。

标准表、自建表、CDS视图、AMDP在这条链路里的位置不同。自建表全程可控；标准表要遵守SAP规则；CDS视图定义语义层，最终仍落到数据库SQL；AMDP写原生SQL，更接近数据库开发，但仍受SAP管控。无论哪层，底层表索引都是性能底座。上层模型再漂亮，底座没索引，慢查询照样出现。

6.3 索引设计检查清单

下面这份清单是我自己在建索引前会过一遍的，放在这里供你参考。

这份清单不能代替实际测试，但能帮你避免大部分低级错误。索引设计最怕的不是不懂原理，而是凭感觉。先看SQL，再看数据，再看执行计划，最后才动手建索引。建完还要验证、监控、评估写入影响。把这一套流程走顺，ABAP索引才算真正用起来。

我自己现在建索引前必做三件事：先ST05抓真实SQL，再看字段选择性和数据分布，最后问一句这张表写入频不频繁。索引和代码一样，不是越多越好，而是越贴场景越有价值。踩过几次坑之后，我越来越不相信“先建了再说”，更相信执行计划里那几行冷冰冰的访问方式。只要ST05里还是全表扫描，索引就没真正帮上忙。