Challenges and Limitations of Database Sharding in Large‑Scale E‑commerce Systems

Sharding (分库分表) is introduced as a response to MySQL's single‑instance concurrency and storage limits, illustrated by a scenario where 5 million daily orders would require over 1.7 TB of data, far exceeding a single database's capabilities.

The article highlights several critical drawbacks of sharding:

Distributed transactions become unsolvable when multiple tables in the same transaction use different sharding keys, forcing a compromise to eventual consistency.

Non‑sharding attributes cannot be efficiently indexed, making queries such as "orders for a merchant in the last hour" impractical without additional systems like Elasticsearch.

Global primary keys lose their auto‑increment advantage, necessitating external ID generators (UUID, Snowflake, Meituan Leaf, Baidu UidGenerator, etc.).

Global unique constraints cannot be enforced across shards, leading to potential data integrity issues.

Maintaining sharding requires a plethora of custom tools (ShardingSphere, Mycat, distributed ID services, DTS for binlog replication, management back‑ends, DDL automation), increasing architectural complexity.

Scaling the number of shards is costly and risky, often requiring downtime and extensive operational tooling.

Operational burden grows dramatically as the number of database instances multiplies, stressing DBAs and hardware resources.

To address these shortcomings, the article proposes distributed databases as a superior solution. It cites OceanBase's two‑phase commit protocol for strong consistency, global indexes, and native global auto‑increment keys, which reduce the need for custom sharding infrastructure.

Overall, the piece argues that while sharding can temporarily alleviate single‑instance limits, its inherent complexity and consistency trade‑offs make distributed databases the more future‑proof choice for large‑scale applications.