Bạn có đang “đau đầu” vì một câu query SQL, dù rất đơn giản, lại chạy mãi không xong trên một bảng dữ liệu ngày càng “béo phì”? Bạn là dev đang săn lùng từng mili giây hiệu suất, là tester đang vật lộn với những bài test performance, hay đơn giản là người mới tò mò về thế giới dữ liệu?

Nếu câu trả lời là “có”, thì đây chính là “liều thuốc” bạn cần.

Hãy quên đi những định nghĩa khô khan. Hôm nay, chúng ta sẽ khám phá SQL Partitioning – một kỹ thuật “chia để trị” đầy quyền năng – qua những ví dụ đời thường và những bí kíp thực chiến mà bạn sẽ không tìm thấy trong sách vở.

1. SQL Partitioning Là Gì?

Trước hết, Hãy tưởng tượng database của bạn là một cái nhà kho khổng lồ, chứa hàng triệu món đồ (dữ liệu). Khi cần tìm một món đồ, bạn phải chạy khắp cái nhà kho đó. Rất mất thời gian!

Tuy nhiên, nếu bạn chia nhà kho thành các gian nhỏ có nhãn rõ ràng, mọi thứ sẽ khác.

SQL Partitioning chính là việc bạn thông minh sắp xếp nhà kho đó thành các gian hàng nhỏ hơn, được dán nhãn rõ ràng (gọi là các partition – phân vùng):

• Gian hàng “Hóa đơn năm 2023”
• Gian hàng “Hóa đơn năm 2024”
• Gian hàng “Hóa đơn năm 2025”

CREATE TABLE invoice (
    invoice_id INT,
    invoice_date DATE,
    amount DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(invoice_date)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

Khi sếp yêu cầu bạn tìm hóa đơn tháng 12/2024, bạn chỉ việc đi thẳng đến gian hàng “Hóa đơn năm 2024” để tìm. Nhanh hơn gấp bội!

Quan trọng hơn, dù dữ liệu được chia nhỏ ra bên dưới, đối với ứng dụng của bạn nó vẫn là một bảng duy nhất. Đó chính là sự “thần kỳ” của partition.

Lợi ích VÀNG của Partitioning:

• Tăng tốc độ truy vấn “tên lửa”: Khi bạn lọc dữ liệu theo “nhãn” của gian hàng (ví dụ: WHERE OrderDate BETWEEN '2024-01-01' AND '2024-12-31'), hệ thống sẽ chỉ quét gian hàng “2024”, bỏ qua toàn bộ các gian hàng khác. Đây gọi là kỹ thuật Partition Pruning (cắt tỉa phân vùng).
• Quản lý dữ liệu dễ như trở bàn tay: Muốn xóa toàn bộ dữ liệu năm 2020? Thay vì chạy lệnh DELETE hàng triệu dòng và chờ “dài cổ”, bạn chỉ cần “dỡ” cả gian hàng 2020 đi. Xong!
• Bảo trì nhẹ nhàng hơn: Việc bảo trì (như rebuild index) trên một gian hàng nhỏ sẽ nhanh và ít ảnh hưởng đến hệ thống hơn là làm trên cả cái nhà kho.

2. Các “Loại Vũ Khí” Phân Vùng Phổ Biến: Chọn Đúng, Thắng To

Có 3 loại partitioning chính. Việc chọn đúng loại sẽ quyết định sự thành bại của bạn.

RANGE Partitioning (Phân vùng theo Khoảng)

• Ý tưởng: Chia dữ liệu theo một khoảng giá trị liên tục.
• Ví dụ Kinh điển: Phân vùng bảng Sales theo cột OrderDate. Mỗi phân vùng chứa dữ liệu của một tháng hoặc một quý.
• Khi nào dùng: Cực kỳ hoàn hảo cho dữ liệu chuỗi thời gian (time-series) như logs, giao dịch, dữ liệu cảm biến IoT.

LIST Partitioning (Phân vùng theo Danh sách)

• Ý tưởng: Chia dữ liệu theo một danh sách các giá trị cụ thể.
• Ví dụ Kinh điển: Phân vùng bảng Customers theo cột Region (Vùng miền). Một phân vùng cho ‘Miền Bắc’, một cho ‘Miền Trung’, một cho ‘Miền Nam’.
• Khi nào dùng: Phù hợp khi cột phân vùng có một tập hợp các giá trị hữu hạn và rõ ràng (như Tỉnh/Thành, Trạng thái, Loại sản phẩm).

HASH Partitioning (Phân vùng theo Hàm băm)

• Ý tưởng: Tự động phân bổ đều dữ liệu vào một số lượng phân vùng đã định trước.
• Ví dụ Kinh điển: Phân vùng bảng Users theo user_id. Hệ thống sẽ dùng một thuật toán để đảm bảo dữ liệu người dùng được chia đều vào các phân vùng.
• Khi nào dùng: Dùng khi bạn không có cột nào phù hợp cho RANGE hay LIST, và mục tiêu chính là phân tán đều dữ liệu để tránh “điểm nóng”.

3. Bí Kíp Thực Chiến & Những “Cú Lừa” Cần Tránh

Lý thuyết màu hồng, nhưng thực tế thì… không phải lúc nào cũng vậy. Đây là những kinh nghiệm xương máu giúp bạn tránh đi vào “vết xe đổ”.

Hỏi & Đáp Nhanh: Các Lỗi Sai Kinh Điển Khi Dùng Partitioning

Câu hỏi: Tôi đã phân vùng rồi mà query vẫn chậm như rùa. Tôi đã làm sai ở đâu?

Trả lời: Rất có thể bạn đã mắc phải một trong những lỗi sau:

• Chọn sai “Chìa Khóa” (Partition Key): Đây là sai lầm chết người nhất. Nếu các query của bạn không lọc theo cột mà bạn dùng để phân vùng (partition key), thì việc phân vùng hoàn toàn vô dụng. Hệ thống vẫn phải quét tất cả các “gian hàng”.
• “Tham Lam” Chia Quá Nhiều Phân Vùng: Chia nhỏ quá không tốt! Quá nhiều phân vùng sẽ làm tăng gánh nặng quản lý cho database, khiến việc lên kế hoạch truy vấn chậm đi. Vài chục đến vài trăm phân vùng thường là con số hợp lý.
• Dữ Liệu Phân Bổ Không Đều: Nếu 90% dữ liệu của bạn bị dồn vào chỉ một phân vùng, thì lợi ích gần như bằng không. Hãy phân tích dữ liệu trước khi chọn cột phân vùng.
• “Bỏ quên” Index: Partitioning và Indexing là “cặp bài trùng” chứ không phải kẻ thù. Phân vùng giúp giới hạn số lượng dữ liệu cần quét, còn index giúp tìm kiếm nhanh chóng bên trong phân vùng đó.
• Đừng chia quá nhỏ (Over-partitioning)
  Đừng chia mỗi ngày 1 partition nếu bạn có dữ liệu 10 năm (sẽ ra 3650 partitions). Khi partitions quá nhiều:
  • Hệ điều hành quá tải vì mở quá nhiều file.
  • Database tốn tài nguyên để quản lý metadata.
  • Query có thể chậm hơn cả không partition.
  • Lời khuyên: Giữ số lượng partition ở mức hợp lý (dưới 100 thường là con số an toàn cho MySQL, Oracle thì có thể nhiều hơn).
• Cẩn thận với Primary Key: Hầu hết các DB engine (như MySQL) yêu cầu cột dùng để Partition phải nằm trong Primary Key. Điều này có nghĩa là PK của bạn sẽ phải đổi từ (id) sang (id, order_date). Dev team cần lưu ý chỗ này kẻo code logic bị sai.

Kết Luận: Partitioning Là Một Tư Duy, Không Chỉ Là Công Cụ

SQL Partitioning không phải là viên đạn bạc cho mọi vấn đề. Nó là một công cụ quản lý dữ liệu cực kỳ mạnh mẽ ở quy mô lớn, với “tác dụng phụ” tuyệt vời là cải thiện hiệu suất.

Lời khuyên cuối cùng: Đừng vội vàng phân vùng mọi bảng bạn có. Hãy luôn bắt đầu bằng việc tối ưu query và index. Chỉ khi bảng dữ liệu đã thực sự phình to (hàng trăm triệu dòng) và các phương pháp khác đã “bó tay”, đó mới là lúc bạn rút “thanh bảo kiếm” Partitioning ra.

Chúc bạn thành công trên con đường chinh phục dữ liệu!

The post SQL Partitioning: “Chia Để Trị” Dữ Liệu Khổng Lồ appeared first on Tomoshare.

Ở đây tôi có một bài toán từ khách hàng như sau: Hãy tạo cho tao một mã đơn hàng (trans_confirm_no) để tao có thể phân biệt được các đơn hàng với nhau với định dạng như này “TMSxxxxx” và nó sẽ phải bắt đầu từ “TMS00001“.

Ngay khi nhận được yêu cầu thì tôi đã bắt tay ngay vào việc code và ngôn ngữ tôi sử dụng cho dự án này là Java spring boot và MSQL.

Cách sử dụng code để generate mã trans_confirm_no

// hàm tạo ra mã trans_confirm_no mới tăng dần
private synchronized String getTransConfirmNoDiorTest(){
        String maxTransConfirmNo = transactionDiorMapper.getTransConfirmNo();
        log.info("maxTransConfirmNo: {}", maxTransConfirmNo);
        StringBuilder result = new StringBuilder();
        if (StringUtils.isBlank(maxTransConfirmNo)){
            logger.warn("Order transConfirmNo failed, transConfirmNo={}", maxTransConfirmNo);
            result.append("00001");
        } else {
            int maxTransConfirmNoIntValue = Integer.parseInt(maxTransConfirmNo.substring(3)) + 1;
            if (maxTransConfirmNoIntValue > 0 && maxTransConfirmNoIntValue < 100000 ) {
                int len = 5 - ((Integer)maxTransConfirmNoIntValue).toString().length();
                if ( len > 0 ) {
                    for (int i = 0; i < len ; i++) {
                        result.append("0");
                    }
                    result.append(maxTransConfirmNoIntValue);
                } else {
                    result.append(maxTransConfirmNoIntValue);
                }
            } else {
                result.append("00001");
            }
        }
        log.info("result: {}", result);
        return "TMS" + result;
    }

 // hàm lấy ra mã trans_confirm_no lớn nhất đang có
 SELECT
            ttd.trans_confirm_no
        FROM
            t_transaction_dior ttd
        WHERE
            ttd.delete_flag = 0
            AND ttd.trans_confirm_no LIKE 'JPD%'
            AND ttd.trans_status IS NOT NULL
        ORDER BY ttd.trans_confirm_no DESC
        LIMIT 1;

Vấn đề gặp phải ở đây là khi chúng tôi có nhiều đầu api call đến hàm này cùng thời điểm thì việc tạo ra một mã TMSxxxxx tăng dần gặp vấn đề và nó Generate không đúng với mong muốn.

Khi hệ thống có lượng truy cập lớn, số lượng user mua hàng dồn dập, hàm bên trên sẽ xảy ra trường hợp sinh ra các mã trans_confirm_no trùng nhau.

Sử dụng trigger generate mã trans_confirm_no

// Đầu tiên chúng ta tạo ra 1 bảng để sử cơ chế AUTO_INCREMENT trong mysql để  lấy được phần xxxxx nằm trong fomat "TMSxxxxx"
CREATE TABLE transaction_seq
(
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY
);

// Mình tạo ra 1 trigger sử dụng concat để nối prefix TMS + xxxxx đã được gen ở bảng transaction_seq phía trên.
DELIMITER $$
CREATE TRIGGER tg_t_transaction_dior_insert
    BEFORE INSERT ON t_transaction_dior
    FOR EACH ROW
BEGIN
    INSERT INTO transaction_seq VALUES (NULL);
    SET NEW.trans_confirm_no = CONCAT('TMS', LPAD(LAST_INSERT_ID(), 5, '0'));
END$$
    DELIMITER ;

// Đặt giá trị bắt đầu AUTO_INCREMENT trong table transaction_seq
ALTER TABLE transaction_seq AUTO_INCREMENT=00001;

Khi sử dụng trigger đã giải quyết được vấn đề của tôi trong bài toán này.

The post Sử dụng trigger trong SQL Generrate mã code kết hợp một String + id Auto Increament. appeared first on Tomoshare.

Trong blog này, chúng ta sẽ thảo luận về hai engine phổ biến nhất của cơ sở dữ liệu MySQL: InnoDB và MyISAM. Chúng ta sẽ thảo luận về chúng là gì và hiểu MyISAM so với InnoDB bằng cách so sánh chúng với các yếu tố quan trọng.

MySQL là gì?

Khái niệm

Chắc mọi người cũng không còn xa lạ gì với hệ quản trị cơ sở dữ liệu này. MySQL là một open-source RDBMS viết tắt của Relational Database Management Systems (Hệ thống quản lý cơ sở dữ liệu quan hệ mã nguồn mở). MySQL được sử dụng cho nhiều ứng dụng khác nhau và được xây dựng dựa trên SQL (Ngôn ngữ truy vấn có cấu trúc).

Tính năng chính của MySQL

• Dễ sử dụng: Là mã nguồn mở và có rất nhiều bài viết hướng dẫn cài đặt.
• Khả năng mở rộng: MySQL có kiến trúc có thể mở rộng và cung cấp các tiện ích tải nhanh hiệu suất cao với các bộ nhớ đệm khác nhau.
• Khả năng tương thích: MySQL tương thích và có thể được cài đặt trên tất cả các nền tảng hiện đại như Windows, Linux, Unix, MacOS, v.v.
• Bảo mật dữ liệu: MySQL có tất cả các tính năng cung cấp bảo mật cho cơ sở dữ liệu và chỉ cho phép người dùng được ủy quyền truy cập chúng.
• Chi phí thấp: Sử dụng miễn phí. Bất cứ ai đều có thể tải xuống MySQL để sử dụng một cách miễn phí.

MyISAM là gì?

MyISAM là tên viết tắt của My Indexed Sequential Access Method. MyISAM là storage system mặc định và thường được sử dụng trong Web, Data warehousing và các môi trường phân tích khác. MyISAM Engine hỗ trợ tất cả các cấu hình MySQL.

Trước đây, MyISAM được coi là sự lựa chọn tốt hơn, nhanh chóng và tối ưu tốt cho các thao tác đọc nặng. MyISAM là storage engine mặc định cho đến tháng 12 năm 2009; sau đó, InnoDB đã thay thế. Tuy nhiên, MyISAM cung cấp nhiều tiện ích mở rộng hữu ích cho các nhà phát triển MySQL.

InnoDB là gì?

InnoDB là storage engine an toàn giao dịch (tuân thủ ACID) dành cho MySQL với các tính năng như Commit, Rollback và khả năng khôi phục sự cố để bảo vệ dữ liệu người dùng và cung cấp khả năng chịu lỗi.

Khi một transaction hoàn tất, dữ liệu sẽ được ghi vào cơ sở dữ liệu theo transaction đó. Điều quan trọng cần lưu ý là những thay đổi không đầy đủ sẽ không được lưu trữ trong cơ sở dữ liệu.

InnoDB sử dụng row-level locking và tính năng không khóa nhất quán theo kiểu Oracle khi đọc giúp tăng hiệu suất và khả năng đồng thời của nhiều người dùng.

MyISAM vs InnoDB

Nhìn chung, MyISAM là cũ hơn và kém hiệu quả hơn InnoDB. Sự khác biệt thường được ghi nhận nhất giữa hai engine này như sau: InnoDB ổn định hơn, nhanh hơn và dễ cài đặt hơn; nó cũng hỗ trợ các giao dịch. Đây là storage engine mặc định và bạn có thể sử dụng các tính năng của InnoDB mà không cần phải lo lắng về các vấn đề tương thích. Nếu bạn cần lưu trữ lượng lớn dữ liệu hoặc đảm bảo rằng các giao dịch sẽ hoạt động chính xác, hãy chọn InnoDB.

MyISAM không tốt lắm trong việc lưu trữ lượng lớn dữ liệu vì nó lưu trữ mọi thứ trong một bảng duy nhất. Khi cần thêm dữ liệu vào cơ sở dữ liệu, bạn phải khóa toàn bộ bảng, điều này có thể khiến cơ sở dữ liệu của bạn ngừng hoạt động cho đến khi được mở khóa. Còn với InnoDB, mỗi hàng được lưu trữ riêng trong một bảng riêng. Điều này có nghĩa là khi chèn dữ liệu vào cơ sở dữ liệu MySQL, bạn không cần phải khóa tất cả các hàng.

Bây giờ chúng ta hãy chuyển sang phần tổng quan chi tiết hơn về các công cụ lưu trữ này.

1. Engine Type

MyISAM là loại lưu trữ phi giao dịch và mọi tùy chọn ghi đều cần được khôi phục theo cách thủ công (nếu cần).

InnoDB là loại lưu trữ giao dịch tự động khôi phục quá trình ghi nếu chúng chưa được hoàn thành.

2. Locking

Locking là cơ chế trong MySQL ngăn hai người dùng sửa đổi các hàng trùng lặp cùng lúc bằng cách khóa hàng. Người dùng không thể thay đổi bảng khi khóa được bật.

MyISAM sử dụng phương pháp khóa bảng mặc định và cho phép một phiên sửa đổi bảng. Điều này có nghĩa là tại một thời điểm chỉ có một người dùng có thể thay đổi bảng. Nếu người dùng khác cố gắng thay đổi bảng, họ sẽ nhận được thông báo rằng nó đã bị khóa. Phương pháp khóa bảng rất hữu ích cho cơ sở dữ liệu chỉ đọc vì nó không yêu cầu nhiều bộ nhớ.

InnoDB sử dụng khóa cấp hàng của bảng. Phương pháp này hỗ trợ nhiều phiên trên cùng một hàng bằng cách chỉ khóa các hàng trong quá trình sửa đổi. Khóa hàng rất hữu ích cho cơ sở dữ liệu có nhiều người dùng.

Nhược điểm duy nhất của khóa cấp hàng là nó tiêu tốn nhiều bộ nhớ và việc truy vấn cũng như sửa đổi dữ liệu mất nhiều thời gian.

3. Foreign Keys

Khóa ngoại (Foreign Keys) là một cột trong một bảng liên kết dữ liệu với bảng khác. Nó ngăn người dùng thêm các bản ghi phá hủy liên kết giữa hai bảng.

MyISAM không hỗ trợ tùy chọn Khóa ngoại.

InnoDB hỗ trợ tùy chọn Khóa ngoại.

4. ACID Properties

ACID là viết tắt của Atomicity, Consistency, Isolation, và Durability. MyISAM không hỗ trợ thuộc tính ACID trong khi InnoDB hỗ trợ thuộc tính ACID.

5. Performance

InnoDB hỗ trợ các thuộc tính transaction, tức là rollback và commit, đồng thời có tốc độ ghi cao hơn. Hiệu suất của InnoDB đối với khối lượng dữ liệu lớn tốt hơn so với MyISAM.

MyISAM không hỗ trợ các thuộc tính transaction và đọc nhanh hơn. So với InnoDB, hiệu suất xử lý khối lượng dữ liệu lớn sẽ kém hơn.

6. Reliability

InnoDB sử dụng nhật ký giao dịch để ghi lại mọi hoạt động và do đó cung cấp các hoạt động đáng tin cậy. Vì vậy, trong trường hợp xảy ra lỗi, dữ liệu có thể được phục hồi nhanh chóng bằng cách sử dụng các nhật ký đó.

MyISAM không cung cấp tính toàn vẹn dữ liệu; lỗi phần cứng và các thao tác bị hủy có thể khiến dữ liệu bị hỏng.

7. Caching and Indexing

InnoDB hỗ trợ một lượng lớn bộ đệm lưu trữ cả dữ liệu và chỉ mục index. Tuy nhiên, không có hỗ trợ cho Full-text search.

Bộ đệm khóa MyISAM chỉ dành cho các chỉ mục index và Full-text search được hỗ trợ trong MyISAM.

Conclusion

Bài viết này liệt kê những điểm khác biệt quan trọng giữa 2 loại engine InnoDB và MyISAM. Hy vọng mọi người sẽ hiểu và nắm được những điểm trên để có thể sử dụng hợp lý 2 loại engine này.

Cảm ơn mọi người đã dành thời gian để đọc 🙏

The post MyISAM vs InnoDB appeared first on Tomoshare.

Theo hình ở trên, thứ tự truy vấn được thực hiện theo thứ tự:

Tham khảo: https://www.linkedin.com/posts/nikkisiapno_want-to-know-the-secret-to-optimizing-your-activity-7122893424134934529-Y9U7?utm_source=share&utm_medium=member_desktop

The post Trình tự thực thi SQL appeared first on Tomoshare.

N+1 query là một vấn đề hiệu suất phổ biến trong các ứng dụng Ruby on Rails. Nó xảy ra khi bạn truy vấn một bảng để lấy dữ liệu, sau đó truy vấn bảng khác để lấy dữ liệu bổ sung cho mỗi đối tượng trong bảng đầu tiên.

Ví dụ: Bạn có bảng posts và bảng comments

class Post < ActiveRecord::Base 
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

Bạn muốn lấy danh sách tất cả các bài đăng cùng với danh sách tất cả các bình luận của chúng, bạn có thể viết mã như sau:

@posts = Post.limit(5) 
@posts.each do |post| 
  @post.comments
end
# Total: 6 query 
# 1 query cho post 
# 5 query cho mỗi lần each

Đoạn code này sẽ tạo ra hai truy vấn SQL:
Một truy vấn để lấy tất cả các bài đăng, và một truy vấn cho mỗi bài đăng để lấy tất cả các bình luận của nó. Điều này có thể dẫn đến hiệu suất kém, đặc biệt nếu bạn có nhiều bài đăng hoặc bình luận.

Cách giải quyết N+1

1. Sử dụng includes hoặc eager_load

Phương thức includes hoặc eager_load cho phép bạn tải trước dữ liệu từ relation khi bạn truy cập từ một bảng.

Ví dụ:

@posts = Post.includes(:comments) # Total: 1 query
@posts = Post.eager_load(:comments) # Total: 1 query

2. Sử dụng preload

preload là một phương pháp giúp giảm thiểu vấn đề n+1 query trong Rails. Khi bạn sử dụng preload, Rails sẽ thực hiện hai truy vấn riêng biệt: một truy vấn để lấy tất cả các dữ liệu cần thiết và một truy vấn để lấy dữ liệu liên quan. Sau đó, Rails sẽ kết hợp dữ liệu từ hai truy vấn này mà không cần thực hiện thêm bất kỳ truy vấn nào nữa, giảm thiểu số lần truy vấn đến cơ sở dữ liệu.

Ví dụ:

@posts = Post.preload(:comments)
@posts = Post.preload(:comments).where(published: true)

@posts = Post.all
ActiveRecord::Associations::Preloader.new.preload(@posts, :comments)

3. Sử dụng joins

Sử dụng joins để kết hợp các bảng và truy vấn dữ liệu cùng một lúc. Điều này giúp tránh việc thực hiện nhiều truy vấn riêng lẻ.

Ví dụ:

@posts = Post.joins(:comments).select('posts.*, comments.body') # rails 6
@posts = Post.joins(:comments)
             .select(posts: {}, comments: [:body]) # rails 7

4. Sử dụng pluck hoặc select

Thay vì lấy toàn bộ đối tượng, sử dụng pluck hoặc select để chỉ lấy những cột dữ liệu cần thiết.

Ví dụ:

# Sử dụng pluck
@post_ids = Post.where(created_at: 1.week.ago..).pluck(:id)
@comments = Post.joins(:comments)
                .where(created_at: 1.week.ago..)
		.pluck('comments.id', 'comments.body')

# Sử dụng select
@comments = Comment.select(:id, :body).where(id: @post_ids)
@posts = Post.joins(:comments).select('posts.*, comments.body') # rails 6
@posts = Post.joins(:comments)
             .select(posts: {}, comments: [:body]) # rails 7

5. Sử dụng scope

Khi bạn muốn sử dụng preload với một phạm vi (scope) trong Rails, bạn có thể kết hợp preload với phạm vi đó để tối ưu hóa truy vấn dữ liệu của mình.

Ví dụ:

class Post < ActiveRecord::Base 
  has_many :comments

  scope :published, -> { where(published: true) }
end

@posts = Post.eager_load(:comments).published
@posts = Post.published.preload(:comments)

@posts_pushlished = Post.published
ActiveRecord::Associations::Preloader.new.preload(
  @posts_pushlished,
  :comments
)

@posts = Post.published.includes(:comments)
@posts = Post.published.joins(:comments)

Kết luận

Bằng cách sử dụng các phương pháp như includes, eager_load, preload, joins, pluck, và select, bạn có thể giải quyết vấn đề N+1 query trong Rails một cách hiệu quả. Điều này không chỉ cải thiện hiệu suất ứng dụng của bạn mà còn giúp tối ưu hóa truy vấn cơ sở dữ liệu và tăng tốc độ tải trang.

The post Giải quyết N+1 trong rails appeared first on Tomoshare.

The post SQL Injection appeared first on Tomoshare.