Explain the internal working of Lucene segment merging in Solr?

Every commit or flush in Solr creates a new immutable Lucene segment - a self-contained mini-index. Over time, continuous indexing produces many small segments, and having too many hurts both search speed (each query must check every segment) and disk usage (deleted documents aren't reclaimed until a merge).

Solr addresses this with a merge policy, most commonly TieredMergePolicy, which runs as a background process:

1. It groups segments into size-based "tiers" and periodically selects a set of similarly-sized segments to combine into one larger segment.
2. During the merge, documents marked as deleted (from atomic updates or explicit deletes) are physically dropped, reclaiming disk space.
3. The new merged segment replaces the old ones; old segment files are removed once no searcher still references them.

Key tuning knobs include mergeFactor/tier size (how many segments merge at once - lower means more frequent, smaller merges; higher means fewer, larger, more expensive merges) and the number of concurrent merge threads. Because merging is I/O and CPU intensive, it directly competes with active indexing and query traffic, so bulk-load operations sometimes temporarily use a more aggressive merge policy or trigger an explicit optimize (force-merge to fewer segments) during a maintenance window - though forced full optimizes are used sparingly on SolrCloud since they're expensive and momentarily double disk usage for the affected shard.