# Shopify ຍ້າຍການຈອງສິນຄ້າຄົງຄັງເຂົ້າໄປໃນ MySQL

Published: 2026-10-10

Shopify ໄດ້ຍ້າຍລະບົບການຈອງສິນຄ້າຄົງຄັງຂອງຕົນຈາກ Redis ໄປຍັງຖານຂໍ້ມູນ MySQL ທີ່ໄດ້ເກັບຮັກສາບັນຊີລາຍການສິນຄ້າຄົງຄັງໄວ້ແລ້ວ. ກຸ່ມຂໍ້ມູນແຖວຫົວໜ່ວຍທີ່ສາມາດລັອກໄດ້ແບບສ່ວນຕົວທີ່ມີຂອບເຂດຈຳກັດຊ່ວຍໃຫ້ການສັ່ງຊື້ພ້ອມກັນໃຊ້ SKIP LOCKED ເພື່ອເລືອກຫົວໜ່ວຍທີ່ມີສິດທີ່ແຕກຕ່າງກັນ. ການອອກແບບຍັງຂຶ້ນກັບຂອບເຂດທຸລະກຳ, ຮູບແບບຫຼັກ, ກົດລະບບການເຕີມເຕັມ ແລະ ການສັງເກດເວລາການຖືຄອງການເຊື່ອມຕໍ່ໃນການສັ່ງຊື້.

Canonical: https://thedailydiff.dev/lo/video/shopify-reservation-locks/

## ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

- ຮູບແບບເຄື່ອງນັບປະລິມານ Redis ເກົ່າໄດ້ຈັດການການພ້ອມກັນ, ແຕ່ການລ້າງການຈອງ ແລະ ການອັບເດດບັນຊີລາຍການ MySQL ບໍ່ສາມາດແບ່ງປັນທຸລະກຳປະລໍາມະນູທ້ອງຖິ່ນດຽວໄດ້.
- ການທົດແທນໃຊ້ຫນຶ່ງແຖວຕໍ່ຫນຶ່ງຫົວໜ່ວຍທີ່ມີຢູ່ໃນກຸ່ມທີ່ຈຳກັດຢູ່ທີ່ 1,000 ຕໍ່ການປະສົມປະສານຂອງສິນຄ້າ/ສະຖານທີ່. ກຸ່ມຂໍ້ມູນທີ່ຫວ່າງເປົ່າສາມາດກະຕຸ້ນການເຕີມເຕັມແບບ inline ດ້ວຍຄຳຮ້ອງຂໍທີ່ພ້ອມກັນລໍຖ້າຢູ່ເບື້ອງຫຼັງການລັອກການເຕີມເຕັມ.
- ລະຫັດຫຼັກປະກອບແມ່ນ (shop\_id, inventory\_item\_id, inventory\_group\_id, id). Shopify ໄດ້ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍຂອງການລັອກໃນຕົວແບບຂອງຕົນ ແລະ ໃຊ້ READ COMMITTED ເພື່ອຫຼີກເວັ້ນການລັອກຊ່ອງຫວ່າງທີ່ຂັດຂວາງການເຕີມເຕັມ.
- ການຈອງລຶບແຖວຂໍ້ມູນກ່ອນທີ່ຈະໃສ່ບັນທຶກການຈອງ. ການຢືນຢັນຈະປ່ອຍການລັອກຖານຂໍ້ມູນໃນຂະນະທີ່ການຖືຄອງທີ່ເກັບໄວ້ຍັງຄົງຢູ່ຕໍ່ການຈ່າຍເງິນ; ການຈ່າຍເງິນທີ່ສໍາເລັດຈະຮຽກຮ້ອງບັນຊີລາຍການແລະລຶບການຈອງໃນທຸລະກໍາປະລໍາມະນູຕໍ່ມາ.
- ເອກະສານ MySQL SKIP LOCKED ເປັນມຸມມອງທີ່ບໍ່ສອດຄ່ອງກັນທີ່ບໍ່ລວມແຖວທີ່ຖືກລັອກ. ມັນບໍ່ໄດ້ສ້າງຈໍານວນຫຼັກຊັບທີ່ສົມບູນຫຼືການປ່ຽນແປງທີ່ຍຸດຕິທໍາ, ໃຊ້ໄດ້ກັບການລັອກລະດັບແຖວເທົ່ານັ້ນແລະບໍ່ປອດໄພສໍາລັບການຈຳລອງແບບອີງຕາມຄໍາສັ່ງ.
- ຕົວຢ່າງແຫຼ່ງຂໍ້ມູນລວມມີ expires\_at, ແຕ່ Shopify ບໍ່ໄດ້ບັນທຶກສູດການຄິດໄລ່ການລ້າງຂໍ້ກຳນົດຂອງ MySQL. ສາຂາການປ່ອຍ/ໝົດອາຍຸຂອງວິດີໂອແມ່ນຂໍ້ກຳນົດວົງຈອນຊີວິດທີ່ອະທິບາຍ.
- ເວລາການຖືຄອງການເຊື່ອມຕໍ່ໃນລະຫັດການສັ່ງຊື້ອື່ນໆແມ່ນຂໍ້ຈໍາກັດສຸດທ້າຍຂອງປະສິດທິພາບ. Shopify ໄດ້ຂຽນເງົາທັງສອງລະບົບ, ປຽບທຽບຜົນໄດ້ຮັບ ແລະ ປ່ຽນແປງເທື່ອລະກ້າວດ້ວຍການສັບປ່ຽນປິດ Redis.

## ບົດ

- 0:00 ເປັນຫຍັງຕ້ອງຍ້າຍການຈອງເຂົ້າໄປໃນ MySQL?
- 0:29 ເປັນຫຍັງສອງຮ້ານຈຶ່ງສ່ຽງ?
- 0:52 ຫົວໜ່ວຍທີ່ສາມາດລັອກໄດ້ຈະກາຍເປັນຫຍັງ?
- 1:15 ຈະເກີດຫຍັງຂຶ້ນເມື່ອກຸ່ມຂໍ້ມູນຫວ່າງເປົ່າ?
- 2:14 SKIP LOCKED ປະໄວ້ຫຍັງແດ່?
- 2:26 ເພດານທີ່ແທ້ຈິງຢູ່ໃສ?
- 2:38 ເປັນຫຍັງຂ້ອຍຈຶ່ງຈະສົ່ງການອອກແບບນີ້?

## ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

### ເປັນຫຍັງຕ້ອງຍ້າຍການຈອງເຂົ້າໄປໃນ MySQL?

0:00 ການສັ່ງຊື້ຕ້ອງການ Redis ເພື່ອໃຫ້ໄວ. Shopify ຍ້າຍການຈອງສິນຄ້າຄົງຄັງເຂົ້າໄປໃນ MySQL ໂດຍໃຊ້ແຖວດຽວຕໍ່ຫົວໜ່ວຍໃນ ກຸ່ມຂໍ້ມູນທີ່ມີຂອບເຂດຈຳກັດ. ເປັນຫຍັງຈຶ່ງເລືອກ MySQL? ທ່ານຈະຂ້າມການລັອກຢ່າງປອດໄພໄດ້ແນວໃດ? ນີ້ແມ່ນ The Daily Diff, ຢູ່ເບື້ອງຫຼັງ. ແລະເປັນຫຍັງການສອບຖາມໄວຈຶ່ງຍັງຕິດເພດານ? Shopify ແມ່ນແພລດຟອມການຄ້າສໍາລັບການຂາຍອອນລາຍແລະດ້ວຍຕົວເອງ. Redis ແມ່ນບ່ອນເກັບຂໍ້ມູນໃນໜ່ວຍຄວາມຈຳ.

0:21 MySQL ແມ່ນຖານຂໍ້ມູນເຊື່ອມໂຍງ, ແລະ Shopify ໄດ້ເກັບຮັກສາບັນຊີລາຍການສິນຄ້າຄົງຄັງຂອງຕົນ ຢູ່ທີ່ນັ້ນ. ການຈອງຈະຖືກເກັບໄວ້ໃນສາງໄລຍະສັ້ນໆໃນຂະນະທີ່ຜູ້ຊື້ຈ່າຍເງິນ.

### ເປັນຫຍັງສອງຮ້ານຈຶ່ງສ່ຽງ?

0:29 ຮູບແບບ Redis ຂອງພວກເຂົາໄດ້ຫຼຸດເຄື່ອງນັບລາຍການລົງ. ການຮຽກຮ້ອງຄໍາສັ່ງທີ່ຈ່າຍແລ້ວໝາຍເຖິງການອັບເດດບັນຊີລາຍການ MySQL ແລະການລຶບລ້າງ Redis. ການຂຽນແຍກກັນເຫຼົ່ານັ້ນສາມາດເຮັດໃຫ້ສິນຄ້າຂາຍໄດ້ສອງຄັ້ງ ຫຼືບໍ່ມີໃຫ້ບໍລິການເມື່ອຄວນຈະ ສາມາດຂາຍໄດ້. ຮູບແບບເກົ່າກໍ່ຂາດການຮັບຮູ້ສະຖານທີ່. ການທົດແທນຕ້ອງເລືອກຫຼັກຊັບຈາກບ່ອນໃດບ່ອນໜຶ່ງທີ່ສາມາດຕອບສະຫນອງຄໍາສັ່ງໄດ້. ສາງຢູ່ທະວີບທີ່ຜິດພາດເຮັດໃຫ້ການປ້ອນຂໍ້ມູນຖານຂໍ້ມູນທີ່ດີເລີດ ແລະເປັນ ຄຳໝັ້ນສັນຍາການຈັດສົ່ງທີ່ຮ້າຍແຮງ. ຄວາມພະຍາຍາມ MySQL ກ່ອນໜ້ານີ້ໄດ້ໃຊ້ແຖວປະລິມານ, ດັ່ງນັ້ນການສັ່ງຊື້ທີ່ແຂ່ງຂັນກັນຈຶ່ງຖືກຈັດລຽງຢູ່ທີ່

### ຫົວໜ່ວຍທີ່ສາມາດລັອກໄດ້ຈະກາຍເປັນຫຍັງ?

0:56 ການລັອກດຽວກັນ. ຄິດເຖິງເຊືອກກຳມະຫຍີ່ອ້ອມຮອບຫ້ອງສະເປຣດຊີດ. ການເພີ່ມຄົນງານຫຼາຍຂຶ້ນພຽງແຕ່ເຮັດໃຫ້ແຖວຍາວຂຶ້ນ. Shopify ໄດ້ປ່ຽນວັດຖຸທີ່ສາມາດລັອກໄດ້. ແຕ່ລະຫົວໜ່ວຍທີ່ມີຢູ່ຈະໄດ້ຮັບແຖວຂອງຕົນເອງ. ການອ່ານແບບລັອກຂ້າມຫົວໜ່ວຍອື່ນທີ່ ທຸລະກຳຖືຢູ່ ແລະເລືອກຫົວໜ່ວຍອື່ນໆ ທີ່ມີສິດ. ພະນັກງານທີ່ແຕກຕ່າງກັນສາມາດໄດ້ຮັບແຖວທີ່ແຕກຕ່າງກັນ, ໃນຂະນະທີ່ເຄື່ອງນັບທີ່ຮ້ອນບໍ່ເຂົ້າມາຂັດຂວາງ.

### ຈະເກີດຫຍັງຂຶ້ນເມື່ອກຸ່ມຂໍ້ມູນຫວ່າງເປົ່າ?

1:15 ກຸ່ມຂໍ້ມູນນັ້ນຖືກຈຳກັດຢູ່ທີ່ໜຶ່ງພັນແຖວຕໍ່ລາຍການ ແລະສະຖານທີ່. ການເຕີມເຕັມດຶງມາຈາກບັນຊີລາຍການ. ຖ້າມັນຫວ່າງເປົ່າ, ເສັ້ນທາງ ການຈອງຈະເຕີມເຕັມແບບ inline, ດ້ວຍຄຳຮ້ອງຂໍທີ່ແຂ່ງຂັນກັນ ລໍຖ້າຢູ່ເບື້ອງຫຼັງການລັອກການເຕີມເຕັມ. ກຸ່ມຂໍ້ມູນທີ່ຫວ່າງເປົ່າບໍ່ໄດ້ໝາຍເຖິງສາງທີ່ຫວ່າງເປົ່າ. ການຈອງລຶບແຖວຂໍ້ມູນທີ່ເລືອກ, ຈາກນັ້ນໃສ່ບັນທຶກການຈອງໃນ ທຸລະກໍາ. ການຢືນຢັນຈະປ່ອຍການລັອກຖານຂໍ້ມູນ.

1:35 ການຍົກເລີກການປ່ຽນແປງ. ການຈອງຍັງຄົງຢູ່ຕໍ່ການປະມວນຜົນການຈ່າຍເງິນເປັນສະຖານະທີ່ເກັບໄວ້. ການຈ່າຍເງິນທີ່ສໍາເລັດຈະຮຽກຮ້ອງບັນຊີລາຍການແລະລຶບການຈອງແບບປະລໍາມະນູ. ການລັອກຖານຂໍ້ມູນບໍ່ຈໍາເປັນຕ້ອງເຝົ້າແບບຟອມການຈ່າຍເງິນ. ລະຫັດຫຼັກປະກອບຂອງພວກເຂົາເລີ່ມຕົ້ນດ້ວຍຮ້ານຄ້າ, ສິນຄ້າ, ກຸ່ມ, ຫຼັງຈາກນັ້ນລະຫັດຫົວໜ່ວຍ. ການຈັບຄູ່ການຄົ້ນຫາຫຼຸດຜ່ອນການລັອກດັດສະນີໃນຕົວແບບຂອງພວກເຂົາ. ພວກເຂົາຍັງໃຊ້ການອ່ານທີ່ຖືກຢືນຢັນເພື່ອຫຼີກເວັ້ນການລັອກຊ່ອງຫວ່າງທີ່ຂັດຂວາງການເຕີມເຕັມກຸ່ມຂໍ້ມູນ,

1:57 ແລະຄໍາສັ່ງຕາຕະລາງທີ່ສອດຄ່ອງກັນເພື່ອປ້ອງກັນການລໍຖ້າແບບວົງຈອນ. ຕົວຢ່າງທີ່ເຜີຍແຜ່ບັນທຶກເວລາໝົດອາຍຸ. ການຈ່າຍເງິນທີ່ຖືກປະຖິ້ມຕ້ອງການການປ່ອຍສິນຄ້າຄົງຄັງໃນທີ່ສຸດ, ຖ້າບໍ່ດັ່ງນັ້ນກະຕ່າສິນຄ້າຈະກາຍເປັນ ເຈົ້າຂອງເຮືອນ. ຂໍ້ຄວາມຂອງ Shopify ປະຖິ້ມສູດການຄິດໄລ່ການລຶບລ້າງນັ້ນບໍ່ໄດ້ລະບຸ, ດັ່ງນັ້ນແຜນວາດນີ້ສະແດງໃຫ້ເຫັນຂໍ້ກຳນົດວົງຈອນຊີວິດ. ນີ້ແມ່ນບັນຫາ.

### SKIP LOCKED ປະໄວ້ຫຍັງແດ່?

2:14 Skip locked ຍົກເວັ້ນແຖວທີ່ຖືກລັອກ, ດັ່ງນັ້ນຄູ່ມືຈຶ່ງເອີ້ນຜົນໄດ້ຮັບຂອງມັນວ່າເປັນມຸມມອງທີ່ບໍ່ສອດຄ່ອງກັນ. ມັນບໍ່ໄດ້ໃຫ້ຈໍານວນຫຼັກຊັບທີ່ສົມບູນຫຼືການປ່ຽນແປງທີ່ຍຸດຕິທໍາ. ຮັກສາການຕັດສິນໃຈທີ່ມີຢູ່ແລະກົດລະບຽບການເຕີມເຕັມຢູ່ອ້ອມຮອບມັນ.

### ເພດານທີ່ແທ້ຈິງຢູ່ໃສ?

2:26 ແລະເພດານນັ້ນ? ລະຫັດການສັ່ງຊື້ອື່ນໆກໍາລັງຖືການເຊື່ອມຕໍ່ຖານຂໍ້ມູນດົນເກີນໄປ. Shopify ໄດ້ຕິດປ້າຍຜູ້ໂທ ແລະວັດແທກເວລາການຖືຄອງການເຊື່ອມຕໍ່, ຈາກນັ້ນໄດ້ລ້າງເສັ້ນທາງການສັ່ງຊື້ ແລະທົບທວນຄືນການພ້ອມກັນຂອງ thread. ການສອບຖາມໄວສາມາດຍັງຖືກຈັດລຽງຢູ່ນອກການສອບຖາມໄດ້.

### ເປັນຫຍັງຂ້ອຍຈຶ່ງຈະສົ່ງການອອກແບບນີ້?

2:38 ພວກເຂົາໄດ້ຂຽນເງົາທັງສອງລະບົບດ້ວຍ Redis ທີ່ເປັນທາງການ, ປຽບທຽບຜົນໄດ້ຮັບ, ຈາກນັ້ນປ່ຽນແປງເທື່ອລະກ້າວດ້ວຍປຸ່ມປິດ. ຄໍາຕັດສິນຂອງຂ້ອຍຄື SHIP IT. ຂ້ອຍຈະຈັດສົ່ງຂອບເຂດທຸລະກໍາທີ່ແບ່ງປັນແລະການນໍາໃຊ້ທີ່ສາມາດຍົກເລີກໄດ້ນັ້ນ, ໂດຍມີເສັ້ນທາງການສັ່ງຊື້ທັງໝົດຖືກກວດສອບ. ມີຄໍາຖາມກ່ຽວກັບເລື່ອງນີ້ບໍ? ໃສ່ໄວ້ໃນຄໍາເຫັນ. ແລະນັ້ນຄື diff ສໍາລັບມື້ນີ້.

2:54 ຂ້ອຍຄື Niko ຈາກ Axrisi. ລວມເຂົ້າກັນຢ່າງມີຄວາມຮັບຜິດຊອບ.

## ແຫຼ່ງຂໍ້ມູນ

- [We replaced Redis with MySQL for inventory reservations—and it scaled](https://shopify.engineering/scaling-inventory-reservations) — Shopify Engineering — Emilie Noel
- [Simplified reservation SQL embedded in Shopify's article](https://gist.github.com/CourtneySymons/cb5ecbe86331047aae166d5b1f1d555c) — Shopify Engineering / CourtneySymons on GitHub Gist
- [MySQL 8.0 — Locking Reads](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) — Oracle / MySQL Reference Manual
- [MySQL 8.0 — Transaction Isolation Levels](https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html) — Oracle / MySQL Reference Manual
- [What Is Shopify and How Does It Work?](https://www.shopify.com/blog/what-is-shopify) — Shopify
- [Redis quick starts](https://redis.io/docs/latest/develop/get-started/) — Redis documentation
- [What is MySQL?](https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.html) — Oracle / MySQL Reference Manual