DB Index

Indexes make reads faster but writes slower. The tradeoff is clear

• Index is for fast Select

• Time-based indexing is inefficient
• Creates overhead for data that changes frequently
• Makes time-range queries faster but at a cost

• String indexing has limitations
• Takes up more space than numeric indices
• Consider encoding strings as integers when possible (e.g., for UUID if not natively supported by the database)

• Best practices for indexing
• Only index columns that truly need it
• Indexed columns don't truly have "UPDATE" operations - they work as DELETE + INSERT behind the scenes
• Each additional index increases storage requirements and memory usage

• Know the limitations
• Databases are not search engines - avoid ngram indexing when possible
• For large string searches, synchronize with dedicated solutions like Elasticsearch

UUID performance in MySQL?

At my job, we use UUID as PKs. What I can tell you from experience is DO NOT USE THEM as PKs (SQL Server by the way). It's one of those things that when you have less than 1000 records it;s ok, but when you have millions, it's the worst thing you can do.

https://stackoverflow.com/questions/2365132/uuid-performance-in-mysql