I’ve done dutiful DBA work in the past to identify and remove what are commonly called duplicate indexes. That is, those indexes that look like (a) and (a,b). The thought is that a query will utilize an index as easily on (a) as on (a,b), and removing (a) will save storage cost and write performance. I’ve had the experience, though, of removing (a) and seeing performance tank. Why do we sometimes want to keep duplicate indexes?
- I was reminded recently of a project I did during a DevDays week at WebAssign in 2014. The engineering department wanted to move a large dataset into MongoDB, and my DevDays experiment was to demonstrate the Tungsten Replicator’s role in translating data from MySQL to MongoDB. It worked handily, but was ultimately not implemented because the development teams got bogged down in the Tungsten replication filters desired for data transformation.