MySQL phát triển từ các site LAMP ban đầu tới hệ production lưu lượng lớn ngày nay: các lựa chọn thiết kế chính, InnoDB, replication, sharding, và các mẫu scale thực tế.
MySQL trở thành cơ sở dữ liệu được chọn cho web đầu tiên vì một lý do đơn giản: nó phù hợp với những gì các website cần lúc đó — lưu và truy vấn dữ liệu có cấu trúc nhanh, chạy trên phần cứng khiêm tốn, và dễ vận hành cho các đội nhỏ.
Nó dễ tiếp cận. Bạn có thể cài nhanh, kết nối từ các ngôn ngữ lập trình phổ biến, và đưa một site vào hoạt động mà không cần thuê quản trị cơ sở dữ liệu chuyên dụng. Sự kết hợp giữa “hiệu năng đủ tốt” và chi phí vận hành thấp đã biến nó thành lựa chọn mặc định cho startup, dự án cá nhân, và doanh nghiệp đang phát triển.
Khi người ta nói MySQL “scale”, thường họ ám chỉ một sự pha trộn của:
Các công ty web ban đầu không chỉ cần tốc độ; họ cần hiệu năng và thời gian hoạt động có thể dự đoán trong khi kiểm soát chi phí cơ sở hạ tầng.
Câu chuyện scale của MySQL thực chất là câu chuyện về các đánh đổi thực tế và các mẫu lặp lại được:
Đây là một chuyến tham quan các mẫu mà các đội sử dụng để giữ MySQL hoạt động dưới lưu lượng web thực tế — không phải một cuốn sổ tay MySQL đầy đủ. Mục tiêu là giải thích cách database phù hợp với nhu cầu web, và vì sao những ý tưởng đó vẫn xuất hiện trong các hệ thống sản xuất lớn ngày nay.
Thời điểm MySQL bùng nổ gắn chặt với sự trỗi dậy của shared hosting và các đội nhỏ xây dựng web nhanh. Không chỉ vì MySQL “đủ tốt” — nó phù hợp với cách web đầu tiên được triển khai, quản lý và trả phí.
LAMP (Linux, Apache, MySQL, PHP/Perl/Python) hiệu quả vì nó khớp với cấu hình mặc định mà hầu hết người ta có thể chi trả: một máy Linux chạy web server và cơ sở dữ liệu cạnh nhau.
Nhà cung cấp hosting có thể tạo template cho cấu hình này, tự động hóa cài đặt, và cung cấp với giá rẻ. Lập trình viên có thể giả định môi trường cơ bản giống nhau ở hầu hết nơi, giảm bất ngờ khi chuyển từ phát triển local sang production.
MySQL đơn giản để cài, khởi động và kết nối. Nó nói SQL quen thuộc, có client dòng lệnh đơn giản, và tích hợp tốt với các ngôn ngữ/framework phổ biến thời đó.
Cách vận hành cũng dễ tiếp cận: một tiến trình chính, vài file cấu hình, và các mode hỏng hóc rõ ràng. Điều đó làm cho việc một sysadmin tổng quát (và thường là các developer) chạy được database mà không cần đào tạo chuyên sâu.
Là mã nguồn mở giúp loại bỏ ma sát bản quyền ban đầu. Một dự án sinh viên, một diễn đàn cá nhân, và một site kinh doanh nhỏ đều có thể dùng cùng engine cơ sở dữ liệu với các công ty lớn.
Tài liệu, mailing list, và sau này là hướng dẫn trực tuyến tạo động lực: nhiều người dùng hơn nghĩa là nhiều ví dụ hơn, nhiều công cụ hơn, và khắc phục lỗi nhanh hơn.
Phần lớn site ban đầu đọc nhiều và khá đơn giản: diễn đàn, blog, các trang CMS, và catalog thương mại điện tử nhỏ. Những ứng dụng này thường cần tra cứu nhanh theo ID, các bài viết mới nhất, tài khoản người dùng, và lọc/tìm kiếm cơ bản — đúng loại workload mà MySQL xử lý hiệu quả trên phần cứng khiêm tốn.
Các triển khai MySQL ban đầu thường bắt đầu là “một server, một database, một app.” Điều đó ổn cho một diễn đàn hobby hoặc site công ty nhỏ — cho đến khi app trở nên phổ biến. Lượt xem trang trở thành các session, session trở thành lưu lượng liên tục, và database ngừng là một thành phần yên tĩnh ở phía sau.
Hầu hết app web vốn (và vẫn) đọc nhiều hơn ghi. Một homepage, danh sách sản phẩm, hay trang hồ sơ có thể được xem hàng nghìn lần cho mỗi lần cập nhật. Sự mất cân bằng đó định hình các quyết định scale ban đầu: nếu bạn có thể làm cho việc đọc nhanh hơn — hoặc tránh chạm database cho đọc — bạn có thể phục vụ nhiều người hơn mà không cần viết lại mọi thứ.
Nhưng: ngay cả ứng dụng đọc nhiều cũng có các ghi quan trọng. Đăng ký, mua hàng, bình luận, và cập nhật admin không thể bỏ. Khi lưu lượng tăng, hệ thống phải xử lý cả luồng đọc lớn và các ghi “phải thành công” cùng lúc.
Ở lưu lượng cao hơn, vấn đề trở nên rõ ràng bằng các thuật ngữ đơn giản:
Các đội học cách chia nhiệm vụ: app xử lý logic nghiệp vụ, một cache hấp thụ các đọc lặp lại, và database tập trung vào lưu trữ chính xác và các truy vấn thiết yếu. Mô hình tư duy đó mở đường cho bước tiếp theo như tinh chỉnh truy vấn, chỉ mục tốt hơn, và scale ngang bằng replica.
Điều đặc biệt về MySQL là nó không chỉ là “một engine database” bên dưới. Đó là một server database có thể lưu và truy xuất dữ liệu bằng các storage engine khác nhau.
Ở mức cao, storage engine là phần quyết định cách hàng được ghi vào đĩa, cách chỉ mục được duy trì, cách khoá hoạt động, và chuyện gì xảy ra sau một crash. SQL của bạn có thể giống hệt, nhưng engine quyết định database hành xử giống một cuốn sổ nhanh — hay giống một sổ cái ngân hàng.
Trong một thời gian dài, nhiều thiết lập MySQL dùng MyISAM. Nó đơn giản và thường nhanh cho các site đọc nhiều, nhưng có các đánh đổi:
InnoDB đảo ngược các giả định đó:
Khi web app chuyển từ chỉ đọc trang sang xử lý đăng nhập, giỏ hàng, thanh toán và nhắn tin, độ chính xác và phục hồi quan trọng ngang bằng với tốc độ. InnoDB làm cho việc scale trở nên thực tế mà không lo restart hay spike lưu lượng sẽ làm hỏng dữ liệu hoặc làm tắc toàn bộ bảng.
Kết luận thực tế: chọn engine ảnh hưởng đến cả hiệu năng và an toàn. Đó không chỉ là một ô để tích — mô hình khoá, hành vi lỗi, và đảm bảo của app đều phụ thuộc vào nó.
Trước khi sharding, read replicas, hay cache phức tạp, nhiều chiến thắng MySQL ban đầu đến từ một thay đổi nhất quán: làm cho truy vấn có chi phí dự đoán được. Chỉ mục và thiết kế truy vấn là bộ “nhân” đầu tiên vì chúng giảm lượng dữ liệu MySQL phải chạm cho mỗi yêu cầu.
Hầu hết chỉ mục MySQL là dạng B-tree. Hãy nghĩ chúng như một danh bạ có thứ tự: MySQL có thể nhảy tới vị trí đúng và đọc một lát nhỏ, liên tục của dữ liệu. Không có chỉ mục đúng, server thường phải quét hàng từng hàng. Ở lưu lượng thấp điều đó chỉ chậm; ở quy mô, nó khuếch đại lưu lượng — nhiều CPU hơn, nhiều I/O đĩa hơn, nhiều thời gian khoá hơn, và độ trễ cao hơn cho mọi thứ khác.
Một vài mẫu lặp lại gây ra lỗi “chạy được ở staging”:
SELECT *: kéo các cột không cần thiết, tăng I/O, và có thể làm mất lợi ích của covering index.WHERE name LIKE '%shoe' không thể dùng hiệu quả chỉ mục B-tree thông thường.WHERE DATE(created_at) = '2025-01-01' thường ngăn dùng chỉ mục; ưu tiên bộ lọc khoảng như created_at >= ... AND created_at < ....EXPLAIN và slow logs thành công cụ hàng ngàyHai thói quen có hiệu quả hơn bất cứ mẹo thông minh nào:
EXPLAIN để xác minh bạn đang dùng chỉ mục như ý và không quét.Thiết kế chỉ mục quanh cách sản phẩm hoạt động:
(user_id, created_at) làm “mục mới nhất” nhanh.Chỉ mục tốt không phải là “nhiều chỉ mục hơn.” Mà là vài chỉ mục đúng, khớp với đường dẫn đọc/ghi quan trọng.
Khi một sản phẩm dùng MySQL bắt đầu chậm lại, quyết định lớn đầu tiên là scale lên (dọc) hay scale ra (ngang). Chúng giải quyết các vấn đề khác nhau — và thay đổi cuộc sống vận hành theo những cách rất khác.
Scale dọc nghĩa là cung cấp cho MySQL nhiều tài nguyên trên một máy: CPU nhanh hơn, nhiều RAM hơn, lưu trữ tốt hơn.
Điều này thường hoạt động tốt vì nhiều điểm nghẽn là ở cục bộ:
Scale dọc thường là chiến thắng nhanh nhất: ít phần chuyển động, mode lỗi đơn giản hơn, và ít thay đổi ứng dụng. Nhược điểm là luôn có trần (và nâng cấp có thể đòi downtime hoặc di cư rủi ro).
Scale ngang thêm máy. Với MySQL, đó thường là:
Nó khó hơn vì bạn đưa vào các vấn đề điều phối: replication lag, hành vi failover, các đánh đổi nhất quán, và công cụ vận hành. Ứng dụng cũng phải biết nói với server nào (hoặc bạn cần lớp proxy).
Hầu hết đội không cần sharding đầu tiên. Bắt đầu bằng xác định nơi mất thời gian (CPU vs I/O vs contention), sửa truy vấn chậm và chỉ mục, và điều chỉnh RAM/ổ phù hợp. Scale ngang có lợi khi một máy đơn không thể đáp ứng write rate, kích thước lưu trữ, hoặc yêu cầu availability — ngay cả sau khi tối ưu kỹ.
Replication là một trong những cách thực tế nhất hệ thống MySQL xử lý tăng trưởng: thay vì một database gánh mọi thứ, bạn sao chép dữ liệu sang các server khác và phân tán công việc.
Hãy nghĩ về một primary (hay “master”) là database nhận các thay đổi — INSERT, UPDATE, DELETE. Một hoặc nhiều replica liên tục kéo các thay đổi đó và áp dụng, giữ một bản sao gần như thời gian thực.
Ứng dụng của bạn sau đó có thể:
Mẫu này phổ biến vì lưu lượng web thường tăng “đọc nhiều” nhanh hơn “ghi nhiều.”
Read replicas không chỉ giúp phục vụ trang nhanh hơn. Chúng còn giúp tách biệt công việc làm chậm primary:
Replication không miễn phí. Vấn đề phổ biến nhất là replication lag — replica có thể chậm vài giây (hoặc hơn) so với primary khi spike.
Điều đó dẫn đến câu hỏi ở mức ứng dụng: đọc-thấy-ngay-ghi. Nếu người dùng cập nhật hồ sơ và bạn đọc ngay từ replica, họ có thể thấy dữ liệu cũ. Nhiều đội giải quyết bằng cách đọc từ primary cho các view “tươi,” hoặc dùng một cửa sổ ngắn “đọc từ primary sau khi ghi”.
Replication sao chép dữ liệu; nó không tự động giữ bạn trực tuyến khi gặp lỗi. Failover — nâng một replica lên primary, chuyển hướng traffic, và đảm bảo app kết nối lại an toàn — là khả năng riêng đòi hỏi công cụ, thử nghiệm và quy trình vận hành rõ ràng.
Độ sẵn sàng cao (HA) là tập các thực hành giữ ứng dụng chạy khi server DB chết, link mạng rớt, hoặc cần bảo trì. Mục tiêu đơn giản: giảm downtime, làm cho bảo trì an toàn, và đảm bảo việc phục hồi có thể dự đoán thay vì ứng biến.
Các triển khai MySQL ban đầu thường bắt đầu với một primary. HA thường thêm máy thứ hai để lỗi không đồng nghĩa với outage dài.
Tự động hoá giúp, nhưng cũng đặt ra thách thức: đội phải tin vào logic phát hiện và tránh “split brain” (hai server nghĩ mình là primary).
Hai chỉ số giúp quyết định HA trở nên rõ ràng:
HA không chỉ là topo — nó là thực hành.
Backup phải định kỳ, nhưng quan trọng là kiểm tra phục hồi: bạn có thật sự khôi phục được tới server mới, nhanh, khi chịu áp lực? Thay đổi schema cũng quan trọng. Thay đổi bảng lớn có thể khoá ghi hoặc làm chậm truy vấn. Các cách an toàn hơn bao gồm chạy thay đổi vào giờ thấp điểm, dùng công cụ thay đổi schema online, và luôn có kế hoạch rollback.
Làm tốt, HA biến lỗi từ khủng hoảng thành sự kiện được lên kế hoạch và diễn tập.
Cache là một trong những cách đơn giản nhất các đội web ban đầu giữ MySQL phản hồi khi lưu lượng tăng. Ý tưởng rõ ràng: phục vụ các yêu cầu lặp lại từ thứ gì đó nhanh hơn DB, và chỉ chạm MySQL khi cần. Nếu làm tốt, cache giảm mạnh tải đọc và khiến các đột biến lưu lượng giống như leo dốc nhẹ thay vì một cuộc náo loạn.
Cache ứng dụng/object lưu các “mảnh” dữ liệu mà code thường yêu cầu — hồ sơ người dùng, chi tiết sản phẩm, kiểm tra quyền. Thay vì chạy cùng một SELECT hàng trăm lần mỗi phút, app đọc một object đã được tính sẵn theo key.
Cache trang hoặc mảnh trang lưu HTML đã render (toàn trang hoặc phần như sidebar). Hiệu quả với site nhiều nội dung nơi nhiều khách xem cùng một trang.
Cache kết quả truy vấn giữ kết quả của một truy vấn cụ thể (hoặc phiên bản chuẩn hoá của nó). Ngay cả khi bạn không cache ở tầng SQL, bạn có thể cache “kết quả endpoint này” dùng key đại diện cho yêu cầu.
Về công cụ, đội dùng store key/value trong RAM, cache HTTP, hoặc cache tích hợp trong framework. Công cụ cụ thể ít quan trọng hơn key nhất quán, TTL (thời gian hết hạn), và ownership rõ ràng.
Cache đổi lấy tính tươi mới bằng tốc độ. Một vài dữ liệu có thể hơi cũ (tin tức, số lượt xem). Dữ liệu khác thì không thể (tổng tiền checkout, quyền). Thường chọn giữa:
Nếu invalidation thất bại, người dùng thấy nội dung lỗi thời. Nếu quá quyết liệt, bạn mất lợi ích và MySQL bị đè bẹp trở lại.
Khi lưu lượng tăng, cache hấp thụ các đọc lặp lại trong khi MySQL tập trung vào “công việc thực sự” (ghi, cache miss, truy vấn phức tạp). Điều này giảm xếp hàng, ngăn hiệu năng chậm lan toả, và mua thời gian để scale an toàn.
Có lúc “phần cứng lớn hơn” và tối ưu truy vấn kỹ không còn đủ. Nếu một server MySQL đơn không theo kịp volume ghi, kích thước dataset, hoặc cửa sổ bảo trì, bạn bắt đầu xem xét chia dữ liệu.
Partitioning chia một bảng thành các phần nhỏ hơn trong cùng một instance MySQL (ví dụ theo ngày). Nó có thể làm xóa, archive và một số truy vấn nhanh hơn, nhưng không cho phép bạn vượt qua giới hạn CPU, RAM và I/O của máy đó.
Sharding chia dữ liệu trên nhiều server MySQL. Mỗi shard giữ một phần các hàng, và ứng dụng (hoặc lớp định tuyến) quyết định mỗi yêu cầu đi đâu.
Sharding xuất hiện khi:
Một shard key tốt phân bố lưu lượng đều và giữ hầu hết yêu cầu trên một shard:
Sharding đổi sự đơn giản lấy khả năng mở rộng:
Bắt đầu với cache và read replicas để giảm áp lực lên primary. Tiếp theo, cô lập các bảng hoặc workload nặng nhất (đôi khi tách theo tính năng/dịch vụ). Chỉ sau đó chuyển sang sharding — tốt nhất là theo cách cho phép thêm shard dần dần thay vì thiết kế lại toàn bộ.
Chạy MySQL cho một sản phẩm bận rộn ít liên quan đến các tính năng thông minh và nhiều hơn về vận hành kỷ luật. Hầu hết sự cố không bắt đầu bằng một lỗi lớn — chúng bắt đầu bằng các tín hiệu nhỏ mà không ai kết nối kịp thời.
Ở quy mô, bốn chỉ báo “lớn” thường dự báo trouble sớm nhất:
Dashboard tốt thêm ngữ cảnh: lưu lượng, tỷ lệ lỗi, số kết nối, buffer pool hit rate, và các truy vấn hàng đầu. Mục tiêu là phát hiện sự thay đổi — không phải ghi nhớ “bình thường”.
Nhiều truy vấn trông ổn ở staging và thậm chí production giờ thấp. Dưới tải, database cư xử khác: cache không còn đủ, request đồng thời khuếch đại contention, và một truy vấn hơi kém có thể kích hoạt nhiều đọc hơn, nhiều bảng tạm, hoặc sắp xếp lớn hơn.
Đó là lý do các đội dựa vào slow query log, digest truy vấn, và histogram production thực sự thay vì benchmark một lần.
Thực hành thay đổi an toàn nhàm chán có chủ ý: chạy migration theo lô nhỏ, thêm chỉ mục với khoá tối thiểu khi có thể, xác minh bằng explain plan, và giữ rollback thực tế (đôi khi rollback là “dừng rollout và fail over”). Các thay đổi nên đo lường được: độ trễ trước/sau, chờ khoá, và replication lag.
Khi sự cố: xác nhận tác động, tìm thủ phạm hàng đầu (một truy vấn, một host, một bảng), rồi giảm thiểu — điều tiết lưu lượng, kill các truy vấn runaway, thêm chỉ mục tạm thời, hoặc chuyển đổi đọc/ghi. Sau đó, ghi lại những gì đã xảy ra, thêm cảnh báo cho các tín hiệu sớm, và làm cho bản sửa có thể lặp lại để lỗi đó không quay lại tuần sau.
MySQL vẫn là lựa chọn mặc định cho nhiều hệ thống hiện đại vì nó khớp với dạng dữ liệu ứng dụng hàng ngày: nhiều đọc/ghi nhỏ, ranh giới transaction rõ ràng, và truy vấn dự đoán được. Đó là lý do nó vẫn phù hợp với các sản phẩm OLTP như app SaaS, thương mại điện tử, marketplace, và nền tảng đa tenant — nhất là khi bạn mô hình dữ liệu quanh các thực thể nghiệp vụ và giữ transaction cô đọng.
Hệ sinh thái MySQL ngày nay hưởng lợi từ nhiều bài học khó khăn được tích hợp vào các mặc định tốt hơn và thói quen vận hành an toàn hơn. Trong thực tế, các đội dựa vào:
Nhiều công ty giờ chạy MySQL qua dịch vụ quản lý, nơi nhà cung cấp xử lý công việc định kỳ như patch, backup tự động, mã hoá, phục hồi theo thời điểm và các bước scale thông thường (máy lớn hơn, read replicas, tăng storage). Bạn vẫn sở hữu schema, truy vấn và mô hình truy cập dữ liệu — nhưng ít tốn thời gian cho các cửa sổ bảo trì và diễn tập phục hồi.
Một lý do “playbook scale MySQL” vẫn quan trọng là vì đây hiếm khi chỉ là vấn đề database — mà là vấn đề kiến trúc ứng dụng. Các quyết định như tách đọc/ghi, key cache và invalidation, migration an toàn, và kế hoạch rollback vận hành tốt nhất khi được thiết kế cùng sản phẩm, không phải gắn thêm khi sự cố xảy ra.
Nếu bạn đang xây dịch vụ mới và muốn mã hoá những quyết định này sớm, một workflow tạo cảm hứng có thể giúp. Ví dụ, Koder.ai có thể nhận một mô tả bằng ngôn ngữ tự nhiên (thực thể, kỳ vọng lưu lượng, nhu cầu nhất quán) và giúp tạo scaffold app — thường là React cho web và Go cho services — đồng thời giữ bạn kiểm soát tầng dữ liệu. Planning Mode, snapshot và rollback của nó đặc biệt hữu ích khi lặp schema và thay đổi triển khai mà không biến mọi migration thành rủi ro lớn.
Nếu bạn muốn khám phá các hạng mục Koder.ai (Free, Pro, Business, Enterprise), xem /pricing.
Chọn MySQL khi bạn cần: transaction mạnh, mô hình quan hệ, tooling成熟, hiệu năng dự đoán được, và nguồn nhân lực lớn. Xem xét lựa chọn khác khi bạn cần: fan-out ghi khổng lồ với schema linh hoạt (một số hệ NoSQL), ghi đa vùng với nhất quán toàn cầu (cơ sở dữ liệu phân tán chuyên biệt), hoặc workloads ưu tiên phân tích (kho dữ liệu cột).
Bài học thực tế: bắt đầu từ yêu cầu (độ trễ, nhất quán, mô hình dữ liệu, tỷ lệ tăng trưởng, kỹ năng đội), rồi chọn hệ đơn giản nhất đáp ứng được — và MySQL thường vẫn là vậy.
MySQL đạt được vị thế phù hợp với các website đầu tiên vì nó dễ cài đặt, dễ kết nối từ các ngôn ngữ phổ biến, và có hiệu năng “đủ tốt” trên phần cứng khiêm tốn. Kết hợp với tính mở và sự phổ biến của LAMP trên shared hosting, nó trở thành cơ sở dữ liệu mặc định cho nhiều nhóm nhỏ và các site đang phát triển.
Trong bối cảnh này, “scale” thường có nghĩa là xử lý:
Nó không chỉ là tốc độ thô—mà là hiệu năng và thời gian hoạt động có thể dự đoán được dưới tải thực tế.
LAMP làm cho việc triển khai trở nên đáng tin cậy: một máy Linux có thể chạy Apache + PHP + MySQL với chi phí rẻ, và nhà cung cấp hosting có thể chuẩn hoá và tự động hoá. Sự nhất quán đó giảm ma sát khi chuyển từ phát triển local lên production và giúp MySQL lan rộng như một cơ sở dữ liệu “có sẵn”.
Các workload web đầu tiên thường là đọc nhiều và đơn giản: tài khoản người dùng, bài mới nhất, catalog sản phẩm, và lọc cơ bản. MySQL thể hiện tốt cho các tra cứu nhanh (thường theo primary key) và các mẫu truy cập phổ biến như “mục mới nhất”, nhất là khi chỉ mục phù hợp với hành vi truy cập.
Các dấu hiệu ban đầu bao gồm:
Những vấn đề này thường chỉ xuất hiện sau khi lưu lượng tăng, biến các “không hiệu quả nhỏ” thành các đợt trễ lớn.
Một storage engine điều khiển cách MySQL ghi dữ liệu, duy trì chỉ mục, khoá hàng/bảng và phục hồi sau crash. Chọn engine phù hợp ảnh hưởng đến cả hiệu năng và tính đúng đắn—hai hệ thống có thể chạy cùng một SQL nhưng cư xử rất khác dưới tải đồng thời và khi có lỗi.
MyISAM phổ biến ban đầu vì đơn giản và nhanh với workload đọc, nhưng nó dùng khoá ở mức bảng, không có transaction và yếu hơn khi phục hồi sau crash. InnoDB đem lại khoá ở mức hàng, transaction và độ bền tốt hơn—vì vậy khi ứng dụng cần các ghi an toàn (đăng nhập, giỏ hàng, thanh toán) ở quy mô, InnoDB trở thành mặc định tốt hơn.
Chỉ mục giúp MySQL tìm hàng nhanh thay vì quét toàn bộ bảng. Thói quen thực tế quan trọng bao gồm:
SELECT *; chỉ lấy các cột cần thiếtLIKE với wildcard ở đầu và các hàm trên cột đã chỉ mụcEXPLAIN để xác nhận dùng đúng chỉ mụcMục tiêu là chi phí truy vấn có thể dự đoán được dưới tải.
Scale theo chiều dọc (“bigger box”) bổ sung CPU/RAM/ổ nhanh hơn cho một máy—thường là chiến thắng nhanh với ít thay đổi. Scale theo chiều ngang (“nhiều máy hơn”) thêm replica hoặc shard, nhưng đưa vào phức tạp về điều phối (lag sao chép, định tuyến, hành vi failover). Hầu hết nhóm nên tối ưu truy vấn/chỉ mục và điều chỉnh kích thước trước khi chuyển sang sharding.
Replica đọc giúp gửi nhiều truy vấn đọc (và khối lượng báo cáo/backup) tới server phụ trong khi giữ ghi trên primary. Nhược điểm chính là replication lag, có thể phá vỡ kỳ vọng “đọc-thấy-ngay-ghi” — nên ứng dụng thường đọc từ primary ngay sau khi ghi hoặc dùng cửa sổ ngắn “đọc từ primary”.