cám ơn bác đã chia sẻ, cho em ké phát https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-vung-tau/ https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-ba-ria/ https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-chau-duc/ https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-dat-do/ https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-phu-my/ https://congtydietmoiphuongnam.com/diet-moi-tan-goc-tai-xuyen-moc/

Các bạn nên để ý kỹ những lỗi sai này, người viết hồi trước chắc cũng phạm phải và trả giá nên mới rút ra được kinh nghiệm xương máu như vậy, để các bạn sau không đi vào vết xe đổ

Rất cảm ơn tác giả, thật sự cảm động

Bài viết của chuyên gia hàng đầu có khác, thật sự rất bổ ích

@tran.van.tuan Thank bác đã cho thêm thông tin, như mình hiểu thì bài toán của bác chỉ cần tối ưu index là đã giải quyết dc 99% rồi, bản chất của LIMIT...OFFSET thì vẫn không thay đổi.

giả sử kết quả khi không dùng limit...offset có 406713 records
thì khi dùng thêm limit 10 offset 400000, thì vẫn phải scan qua 400000 + 10 (records)
=> Dữ liệu khi chưa dùng limit offset mà càng lớn, và khi dùng limit offset với offset càng lớn thì cũng sẽ bị chậm

dạ cho em hỏi, nếu em có base64 mà muốn preview file excel thì phải làm sao ạ

@sonseait cảm ơn bạn đã góp ý , mình sẽ sớm cập nhật lại !

WSS cụ thể là gì vậy bạn nhỉ, có phải là Web Socket Security không ? Nếu thế thì bạn chỉ cần triển khai JWT filter trong ứng dụng Spring là được. Socket server sẽ dùng chung JWT filter với spring boot application. Có thời gian mình sẽ viết một bài mới về đề tài này nhé, thanks bạn.

Với câu query có LIMIT 10 OFFSET 100000 thì trong bài mình có để rồi nha, là 0.11s. Mình có disable query cache và chạy lại vài lần, thì thời gian rơi vào khoảng 0.11 -> 0.15s.

Trong trường hợp không có LIMIT và OFFSET, mình vừa chạy thử vài lần, kết quả rơi vào khoảng 0.27-0.29s. (Do các id in ra nhiều quá, nên mình thay bằng dấu .... nhé)

mysql> SELECT id FROM articles WHERE deleted_at IS NULL     AND status = 'publish'     AND (publish_datetime <= '2021-12-25 00:00:00' ) ORDER BY hot_factor DESC, publish_datetime DESC, id DESC;

+---------+
| ....... |
| 1680265 |
|  462692 |
+---------+
297766 rows in set (0.28 sec)

Mình có thay đổi giá trị publish_datetime <= 2023-12-25 00:00:00, kết quả trả về vẫn không thay đổi nhiều: 406713 rows in set (0.29 sec)

@onion209 xưa mình crawl tất cả data luôn

@NTruong lâu lâu vào làm bài cho đỡ lụt nghề thôi =))

idol comback rùi💥

@dovannam115 bạn có cách nào lấy dữ liệu giá theo từng quý ko cậu.

@vvvan

2.1 bạn chunk trên cái mảng đã Deserialize rồi thì đâu có tối ưu gì đâu

2.2 bạn split theo , bạn đã test hết các case chưa

"{"data": [{"id": 1, "name": "John Doe", "age": 30}, {"id": 2, "name": "Jane Doe", "age": 25}]}"

mà split theo , thì nó sẽ ra [{"data": [{"id": 1, "name": "John Doe",...] rồi Deserialize theo từng phần tử trong mảng thì làm sao mà đúng được?, rồi ví dụ mà có đúng thì bạn ghép vào thế nào?

Nếu bị confic như sau thì làm sao để tối ưu nhất. git rebase thì các tính năng cũ lại được đưa lên trên các commit mới nhất

@maitrungduc1410 em truy cập vào đây nó không trả về ok mà trả về lỗi ạ 😭 Đây là file laravel-echo-server.json anh ạ

cụ thể như thế nào, bạn có thể góp ý giúp mình ạ. Xin cảm ơn

phần 2 hơi sai sai 😬

Cho mình hỏi là trong trường hợp cuối cùng, bạn chọn index lý tưởng và phù hợp nhất với bài toán rồi, thì khi chạy câu query mà không k có limit...offset với câu query có limit 10 offset 100000, thì mỗi câu đang là bao nhiêu giây?

Kiến thức khá đầy đủ. Thanks bạn nhiều

giải thích k rõ ràng, bài viết khá là vô nghĩa