MySQL用SHOW CREATE TABLE提取索引最直接，过滤KEY相关行即可；PostgreSQL用\d+或pg_indexes查询，优先选原生DDL而非手动拼接。
MySQL 用 SHOW CREATE TABLE 提取索引语句最直接
想单独导出索引（不带表数据、不带表结构），show create table 是最轻量且可靠的方式。它返回建表语句，其中 key 和 unique key 部分就是你要的索引定义。
实操建议：
- 连接数据库后执行：
SHOW CREATE TABLE `user_info`;，查看输出中以KEY开头的行 - 若只要索引部分，可用命令行管道过滤：
mysql -u root -p -e "SHOW CREATE TABLE user_info;" | grep -E "^ KEY|^ UNIQUE KEY|^ PRIMARY KEY" - 注意反引号：表名含特殊字符或关键字时必须用
`包裹，否则语法报错 - 该命令不依赖
INFORMATION_SCHEMA权限，普通只读用户通常也能执行
PostgreSQL 用 \d+ 或查询 pg_indexes
PostgreSQL 没有等价于 SHOW CREATE TABLE 的单条语句，但有两种稳定路径获取索引 DDL：
方法一（交互式）：\d+ table_name 在 psql 中运行，输出末尾的 “Indexes:” 小节列出所有索引名称和定义语句（含 CREATE INDEX）
方法二（SQL 查询）：
SELECT indexdef FROM pg_indexes WHERE tablename = 'orders';
注意点：
-
pg_indexes.indexdef返回的是完整CREATE INDEX语句，但默认不含IF NOT EXISTS，线上重建需手动加 - 索引名可能含 schema 前缀（如
public.idx_orders_user_id），复制使用前确认目标 schema 是否一致 - 函数索引、表达式索引的
indexdef可能含换行或空格，用\x开启扩展显示更清晰
从 INFORMATION_SCHEMA 手动拼 CREATE INDEX 风险高
有人试图从 INFORMATION_SCHEMA.STATISTICS（MySQL）或 pg_class/pg_index（PG）查字段再拼 SQL，这容易出错：
- MySQL 中
STATISTICS表不记录USING BTREE/Hash、COMMENT、KEY_BLOCK_SIZE等细节，拼出来的语句可能缺失关键参数 - PostgreSQL 中
pg_index存储的是内部 OID 映射，不直接暴露表达式内容；函数索引的列定义需关联pg_get_indexdef()函数才准确 - 多列索引顺序、升序/降序（
ASC/DESC）在元数据里分散存储，手工拼接极易颠倒 - 除非自动化脚本有强校验，否则不建议绕过原生 DDL 提取方式
导出时忽略索引的常见误操作
很多人用 mysqldump --no-data 或 pg_dump -s 导出 schema，以为能直接拿到索引语句——其实不是：
-
mysqldump --no-data默认仍会导出索引，但混在CREATE TABLE里，无法“单独提取” -
pg_dump -s导出的是完整 schema，包含CREATE TABLE+CREATE INDEX，但索引语句在文件靠后位置，没做标记，grep 容易漏掉部分（比如被注释或条件判断包裹） - 真正需要“仅索引”的场景（如迁移索引到新集群、审计索引规范），必须用前面提到的针对性命令，而不是依赖 dump 工具的副产品
索引语句看似简单，但隐含的存储引擎参数、排序方向、表达式上下文，稍不注意就会导致重建失败或性能退化。宁可多跑一条命令确认，也不要凭经验补全。
