MySQL performance depends on storage engine, configuration, and replication: (1) InnoDB buffer pool: Set to 70-80% of RAM for caching data/indexes. (2) Indexes: Create indexes on frequently queried columns, avoid over-indexing (slows writes). (3) Replication: Use master-slave for read scaling (1 master, N slaves), route reads to slaves. (4) Query optimization: Use EXPLAIN to analyze queries, avoid SELECT *, use LIMIT. (5) Connection pooling: Reuse connections (avoid connection overhead). (6) Slow query log: Identify slow queries (> 2 seconds), optimize with indexes. Real-world: Facebook uses buffer pool = 70% RAM, 1 master + 100+ slaves for read scaling. YouTube uses connection pooling for billions of queries/day.

Buffer pool: Set to 70-80% of RAM (innodb_buffer_pool_size = 8G), multiple instances for concurrency

Replication: Use for read scaling (1 master, N slaves), route reads to slaves with load balancer

Indexes: Create on frequently queried columns, avoid over-indexing (slows writes), use EXPLAIN

Query optimization: Avoid SELECT *, use LIMIT, use WHERE with indexed columns, avoid functions in WHERE

Connection pooling: Reuse connections (avoid overhead), configure max_connections = 200-500

Generated columns: Use for indexing JSON (STORED), faster than expression indexes

Slow query log: Identify slow queries (> 2 seconds), optimize with indexes or query rewrite

Using MyISAM for transactional data: No transactions, no foreign keys, table-level locking (use InnoDB)

Not configuring buffer pool: Default is too small (128MB), set to 70-80% of RAM

Not using replication for read-heavy workloads: Single database overloaded, use master-slave

Not indexing JSON columns: JSON not indexable directly, use generated columns + indexes

Over-indexing: Too many indexes slow down writes, only index frequently queried columns