MySQL

← Chương trước: Phần 2: Golang vs. PHP/Laravel | Mục lục Series | Chương tiếp theo: Phần 4: MariaDB vs. MySQL → Answer-first: Chọn khóa chính là cuộc đấu giữa kích thước index và tính phân tán: BIGINT (8B) nhanh nhất trên single-node nhưng gây nghẽn sharding; UUIDv7 (16B) loại bỏ node điều phối, tương thích tuyệt đối PostgreSQL (fill factor 99%); còn Snowflake (8B) là “vũ khí tối thượng” cho MySQL/InnoDB chịu tải 50k+ RPS với mật độ B+ Tree hoàn hảo. ...

← Chương trước: Phần 3: UUIDv7 vs Snowflake vs BIGINT | Mục lục Series | Chương tiếp theo: Phần 5: Sharded MySQL vs. TiDB → MariaDB vs. MySQL: Phân Kỳ Kiến Trúc, Storage Engines & Thread Pool Answer-first: MariaDB không còn là bản thay thế trực tiếp của MySQL. MySQL 8.4/9.0 thống trị Cloud-Native (AWS Aurora) nhờ InnoDB tối ưu, Binary JSONB O(1) và native Vector AI. Ngược lại, MariaDB 11.x vượt trội trên Bare-metal/Kubernetes nhờ Open-source ThreadPool (50k+ conns), Galera Multi-Master zero-lag và MyRocks LSM nén 70% đĩa. ...

← Chương trước: Phần 2 — Xử lý tải đột biến: Event-Driven & Kafka (2026) | Mục lục Series | Chương tiếp theo: Phần 4 — Vận hành: SRE & Chaos Engineering (2026) → Answer-first: PayPay chuyển đổi tầng dữ liệu từ Amazon Aurora sang TiDB (Distributed SQL) để giải quyết giới hạn mở rộng ghi và loại bỏ nhu cầu sharding thủ công, đạt khả năng co giãn ngang với độ trễ thấp và tuân thủ chuẩn ACID. ...

← Chương trước: Bài 3: Tấm khiên bảo vệ — Message Queue và Graceful Degradation | Mục lục Series | Chương tiếp theo: Bài 5: Tai mắt của hệ thống — Distributed Tracing với ClickHouse → Answer-first: Để vượt qua giới hạn của MySQL Sharding truyền thống (nghẽn resharding và thiếu ACID phân tán), Shopee chuyển dịch sang TiDB NewSQL. TiDB tách biệt stateless computing (TiDB Server) và stateful storage (TiKV via Raft), hỗ trợ mở rộng ngang tự động và truy vấn phân tán quy mô lớn. ...

← Chương trước: Phần 4: MariaDB vs. MySQL | Mục lục Series | Chương tiếp theo: Phần 6: Apache Kafka vs. NATS JetStream → Sharded MySQL (Vitess) vs. TiDB NewSQL: ACID Phân Tán & Thuế Độ Trễ Mạng Answer-first: Sharded MySQL (Vitess) áp đảo về độ trễ ghi (sub-2ms) và cô lập lỗi (Blast Radius) cho hệ thống E-commerce / SaaS có Sharding Key sạch. Ngược lại, TiDB NewSQL là giải pháp cứu cánh cho schema phức tạp nhờ cơ chế tự động chia tách Region 96MB, chấp nhận mức sàn độ trễ ghi 8–15ms do Percolator 2PC. ...

← Chương trước: Phần 5: Chuyển Đổi Schema EAV Magento | Mục lục Series | Chương tiếp theo: Phần 7: Giai Đoạn 2 — Dual-Write Dapr PubSub → Answer-first: Giai đoạn 1 của mô hình Strangler Fig chỉ di dời luồng truy vấn đọc (Catalog, Search) sang Go microservices, sử dụng Change Data Capture (Debezium CDC) để đồng bộ dữ liệu từ MySQL Magento theo thời gian thực mà không làm gián đoạn luồng ghi nghiệp vụ. ...

Answer-first: Nâng cấp Magento 2.4.5 lên 2.4.8 giải quyết bài toán End-of-Life của MySQL 8.0 trên AWS RDS, tương thích hoàn toàn PHP 8.4 và OpenSearch 2.19. Chiến lược nhảy cóc (Leapfrog) cùng kiến trúc Blue/Green Deployment giảm thiểu downtime về dưới 15 phút, loại bỏ nguy cơ phụ phí Extended Support từ AWS. 1. Quả Bom “Nợ Kỹ Thuật” Mang Tên Cổ Tức Đám Mây Trong thế giới E-commerce B2B và B2C quy mô lớn, nếu hệ thống của bạn vẫn đang chạy Magento 2.4.5 ở thời điểm hiện tại, bạn đang ngồi trên một quả bom nổ chậm mang tên Technical Debt (Nợ kỹ thuật). Ngòi nổ của quả bom này không nằm ở bản thân mã nguồn Magento, mà nằm ở hệ sinh thái hạ tầng bên dưới: ...

MySQL Scalability & Sharding: Vitess vs TiDB (10k+ TPS) Answer-first: Scaling MySQL requires a phased architectural progression: optimizing InnoDB buffer pools (100–500 TPS), implementing ProxySQL read/write splitting (500–3,000 TPS), and migrating to horizontal sharding or TiDB Distributed SQL (3,000–10,000+ TPS). TiDB serves as the premier MySQL sharding alternative, eliminating manual application-level partitioning through stateless SQL compute nodes and Raft-replicated distributed TiKV storage. MySQL scalability is the ability to increase database throughput — reads per second, writes per second, or data volume — without rewriting your application. The critical distinction: read scaling (adding replicas) and write scaling (sharding or distributed SQL) require completely different architectural approaches. Choosing the wrong path creates technical debt that takes months to unwind. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Khi Primary-Replica Read-Scaling chạm trần tải ghi, mở rộng ngang MySQL (Write-Scaling) được thực thi qua Vitess (Middleware-level với VTGate/VTTablet trong suốt, zero-downtime resharding) hoặc GORM Sharding (App-level trong Go qua SQL AST rewrite). Chọn Vitess cho kiến trúc polyglot quy mô lớn; chọn GORM Sharding cho Go stack tinh gọn. Khi ứng dụng của bạn vươn mình chạm ngưỡng hàng triệu người dùng, một cỗ máy database đơn độc (single database instance) sớm muộn gì cũng trở thành nút thắt cổ chai lớn nhất trong toàn bộ kiến trúc. Để giải quyết bài toán này, việc mở rộng quy mô cơ sở dữ liệu MySQL (MySQL database scaling) là điều bắt buộc. Bạn có thể tham khảo Mở Rộng DB Cho Microservices (Scale DB for Microservices) khi áp dụng các kỹ thuật Horizontal Scaling (Mở rộng ngang). Khám phá thêm tại series High Concurrency Systems. ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Scaling a relational database is one of the most demanding challenges in system design. As applications grow from thousands to millions of active users, the database ceases to be a simple storage engine and becomes the primary bottleneck of the entire system architecture. In this technical guide, we explore the architectural progression of scaling MySQL—beginning with replication topologies, stepping through the complexities and operational hazards of manual database sharding (including proxy middleware like Vitess), and evaluating NewSQL alternatives, specifically the distributed architecture of TiDB. ...