<![CDATA[Latest posts for the topic "Cần giúp đỡ về sắp xếp database MySQL"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280248 /hvaonline/posts/list/45564.html#280248 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280270 /hvaonline/posts/list/45564.html#280270 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280419 /hvaonline/posts/list/45564.html#280419 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280422 /hvaonline/posts/list/45564.html#280422 GMT Cần giúp đỡ về sắp xếp database MySQL

henryhuy wrote:
Cảm ơn bác đã phản hồi, mình muốn hỏi thêm là nếu 1 table có 1000 record và 1 table 10000 record thì tốc độ load dữ liệu có khác nhau không nếu mình có limit và order ? 
Khác nhau 10 lần, nói chung đa số trường hợp nếu câu chỉ có limit và order thôi thì sẽ không sử dụng đến index (kể cả order trên cột đã index). MySQL luôn order trước (tức nó lấy hết 1000 hay 1 vạn, 1 triệu ra sort), rồi limit. Phép toán sort là phép toán đắt tiền nên sẽ chậm. Chỉ cần nhớ đến 1 điều này: index chỉ được đụng đến khi cột nó trong where và tên cột được index đó đứng duy nhất một mình bên vế so sánh (=, <, > hoặc between), không có hàm hoặc bất cứ công thức nào, cũng không có cột nào ở vế còn lại. Ví dụ id=xx hoặc id<=xx sẽ dùng index, nhưng left(id,5) = xx thì không (do id không đứng một mình ở vế đó). Hoặc id (là số), ta viết thế này: id >= 5 (cái này có) thì khác hoàn toàn với id - 5 >= 0 (cái này không dùng index). Thế này cũng không index: id >= max_id - 5 (trong đó 2 cột id và max_id cùng 1 bảng, nếu max_id ở bảng khác thì phải có điều kiện where với bảng đó nữa).]]> /hvaonline/posts/list/45564.html#280431 /hvaonline/posts/list/45564.html#280431 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280442 /hvaonline/posts/list/45564.html#280442 GMT Cần giúp đỡ về sắp xếp database MySQL

henryhuy wrote:
Xin gừi bác cấu trúc table của mình như sau : 1 id int(250) 2 content_id varchar(250) 3 content_category_id varchar(255) 4 title text 5 sub_title text 6 detail longtext 7 image varchar(250) 8 idlang varchar(250) 9 show_content int(2) 10 dateadd datetime Câu lệnh SELECT mỗi lần lấy tin mới nhất của mình thế này : "select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content order by id desc limit 0,10" Nếu muốn tạo INDEX thì mình làm thế nào, sorry mình hỏi hơi kỹ vì chưa làm INDEX lần nào cả Mình có đọc 1 số tut trên mạng thì hướng dẫn là ALTER TABLE content ADD INDEX idx_id(id); nhưng mình không rõ là khi nào nên ALTER TABLE cả, có phải là mỗi lần select 10 tin mới ra chăng ? Cảm ơn các bác nhiều. 
Ợ. Vậy là bạn học lập trình SQL mà không học về ... index của CSDL, một thứ quan trọng sống còn của nó (mặc dù hệ thống vẫn chạy khi không có nó), có thể đây là sự thiếu sót không chỉ mỗi bạn mắc phải đâu. Cột ID của bạn có phải là primary key? nếu là primary key rồi thì không cần index nữa vì nó đã được index rồi (primary key là 1 dạng index, với thuộc tính unique). Việc tạo index chỉ 1 lần kèm với tạo bảng, và thi thoảng thì phải bảo dưỡng nó thôi (analyze table), alter table là nhóm DDL như create table... Nếu cột ID của bạn là số tăng dần, mỗi bài tin là tăng 1 đơn vị, bạn lấy 10 tin mới nhất thì sửa 1 chút thế này: select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content where id >= (select max(id)-10 from content) order by id desc limit 0,10 Nếu lo ngại có sự delete trong content, gây lỗ thủng id, thiếu, thì max(id) - 10 thay bằng - 20, - 30... thậm chí 100 vẫn là rất tốt cho bảng. nó đảm bảo rằng dù bảng có tăng kích thước lên thì tốc độ vẫn không thay đổi nhiều.]]> /hvaonline/posts/list/45564.html#280445 /hvaonline/posts/list/45564.html#280445 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280447 /hvaonline/posts/list/45564.html#280447 GMT Cần giúp đỡ về sắp xếp database MySQL /hvaonline/posts/list/45564.html#280664 /hvaonline/posts/list/45564.html#280664 GMT Cần giúp đỡ về sắp xếp database MySQL

myquartz wrote:

henryhuy wrote:
Xin gừi bác cấu trúc table của mình như sau : 1 id int(250) 2 content_id varchar(250) 3 content_category_id varchar(255) 4 title text 5 sub_title text 6 detail longtext 7 image varchar(250) 8 idlang varchar(250) 9 show_content int(2) 10 dateadd datetime Câu lệnh SELECT mỗi lần lấy tin mới nhất của mình thế này : "select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content order by id desc limit 0,10" Nếu muốn tạo INDEX thì mình làm thế nào, sorry mình hỏi hơi kỹ vì chưa làm INDEX lần nào cả Mình có đọc 1 số tut trên mạng thì hướng dẫn là ALTER TABLE content ADD INDEX idx_id(id); nhưng mình không rõ là khi nào nên ALTER TABLE cả, có phải là mỗi lần select 10 tin mới ra chăng ? Cảm ơn các bác nhiều. 
Ợ. Vậy là bạn học lập trình SQL mà không học về ... index của CSDL, một thứ quan trọng sống còn của nó (mặc dù hệ thống vẫn chạy khi không có nó), có thể đây là sự thiếu sót không chỉ mỗi bạn mắc phải đâu. Cột ID của bạn có phải là primary key? nếu là primary key rồi thì không cần index nữa vì nó đã được index rồi (primary key là 1 dạng index, với thuộc tính unique). Việc tạo index chỉ 1 lần kèm với tạo bảng, và thi thoảng thì phải bảo dưỡng nó thôi (analyze table), alter table là nhóm DDL như create table... Nếu cột ID của bạn là số tăng dần, mỗi bài tin là tăng 1 đơn vị, bạn lấy 10 tin mới nhất thì sửa 1 chút thế này: select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content where id >= (select max(id)-10 from content) order by id desc limit 0,10 Nếu lo ngại có sự delete trong content, gây lỗ thủng id, thiếu, thì max(id) - 10 thay bằng - 20, - 30... thậm chí 100 vẫn là rất tốt cho bảng. nó đảm bảo rằng dù bảng có tăng kích thước lên thì tốc độ vẫn không thay đổi nhiều. 
mình xin đính chính chút là nếu cột id đã là primary key rồi thì không cần dùng WHERE... nữa mà chiến luôn: Code:
select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd  from content order by id desc limit 0,10
]]> /hvaonline/posts/list/45564.html#281073 /hvaonline/posts/list/45564.html#281073 GMT Cần giúp đỡ về sắp xếp database MySQL

tmlinhkct wrote:
mình xin đính chính chút là nếu cột id đã là primary key rồi thì không cần dùng WHERE... nữa mà chiến luôn: Code:
select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd  from content order by id desc limit 0,10
 
Câu lệnh này đáp ứng được tiêu chí viết gọn, đẹp nhưng đôi khi nó không chạy như thiết kế và xui xẻo mà developer thay đổi 1 chút thành "order by dateadd" (liệt kê tin từ cũ tới mới chứ không cho mới lên đầu), hoặc primary key không chỉ là id mà thêm category_id thì lúc đó sẽ rất chậm, viết xấu với mệnh đề WHERE sẽ an toàn hơn và không ảnh hưởng nhiều vì câu order by.]]> /hvaonline/posts/list/45564.html#281089 /hvaonline/posts/list/45564.html#281089 GMT Cần giúp đỡ về sắp xếp database MySQL

henryhuy wrote:
càng ngày table chứa tin tức ngày càng phình ra và dường như gây chậm hệ thống đáng kể.  
@tmlinhkct: Chúng ta chú ý vấn đề của chủ topic nhé. Lệnh limit ưu điểm là nhanh, dễ lập trình nhưng phải load hết dữ liệu hợp yêu cầu (load hết nếu không có where) trước khi limit. Ví dụ dữ liệu bạn có 1 triệu instance, máy tính sẽ truy xuất ra 1 triệu, rồi mới limit 10. Việc order ở đây sẽ thực hiện trên 1 triệu instance @@. Bạn @myquartz đưa ra một giải pháp hợp lý, đó là dùng where để gom lại một khoảng instance cố định để order và limit (1000 chẳng hạn), như vậy dù cho dữ liệu của bạn phình ra thêm mấy tỉ nữa thì cũng chỉ truy xuất 1000 instance thôi. Nói thêm tí, thường lập trình viên bọn mình test chỉ khoảng vài chục đến vài trăm instance là cùng (vì làm biếng), nên code của bạn @tmlinhkct sẽ không khác bạn @myquartz mấy, nên ta thường code đơn giản để có thể chạy ngay. Nhưng khi chạy thực tế thì một thời gian sau bị phình dữ liệu, dẫn đến load chậm. ]]> /hvaonline/posts/list/45564.html#281144 /hvaonline/posts/list/45564.html#281144 GMT