# Index Mapping and Risks

Index selection is a business and workload decision. Preserve declared indexes exactly; warn about risks instead of adding, removing, or rewriting them.

## Partial indexes

`partial.condition` uses the schema contract's SQL-like expression and maps by target:

- PostgreSQL: `WHERE` predicate;
- MongoDB: `partialFilterExpression`; use `sparse` only when it is semantically equivalent and the user or project convention selects it;
- MySQL: native partial predicates are limited, so an implementation may need a generated-column or functional-index alternative supported by the deployed version.

Do not select a cross-database substitute silently. Report portability differences.

## Target-specific options

- MongoDB: sparse, TTL, and partial-filter behavior.
- PostgreSQL: BTREE, HASH, GIN, GIST, BRIN, and included columns; validate unsupported combinations such as inappropriate uniqueness semantics.
- MySQL: BTREE, HASH where supported, FULLTEXT, generated columns, and version-specific functional indexes.

## Warnings

- Nullable or low-selectivity fields may create large, low-value indexes.
- Array and nested-field indexes may expand into many index entries.
- Unique indexes change write behavior and can fail on historical duplicates.
- Index builds can lock, consume I/O, or affect mixed-version deployment.
- TTL and partial conditions encode data-lifecycle or query semantics, not only performance.

When the task affects a real deployed database, combine these schema rules with the applicable production rollout and migration constraints.