Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Направление сортировки кластерного индекса и Range Locks
|
|||
|---|---|---|---|
|
#18+
Всем привет! В общем лазил по своим закладкам и нашел статью , "Например, если в базе есть Id 15 и Id 1025, и нет ни одного значения между ними, то при выполнении SELECT * FROM Users WHERE FacebookId = 500 будет наложена Shared блокировка на ключи с 15 до 1025", имеется ввиду при Serializable. Плюс мы тут с коллегой спорили про этот уровень, и главный вопрос был, а так ли это и влияет ли сортировка на блокировки? Решил проверить Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. По итогу. Если индекс уникальный и когда мы выбираем id = 15 (когда в базе есть только 10 и 20), то при индексе ASC Update where id = 10 - проходит Update where id = 20 - нет при индексе DESC Update where id = 10 - нет Update where id = 20 - проходит Если индекс не уникален, то при update также, а вот insert нет, при индексе ASC insert id = 10 - нет insert id = 20 - да, т.е. идет блокировка с 10-19 при индексе Desc insert id = 10 - да insert id = 20 - нет, т.е. идет блокировка с 11-20 Обрыл весь гугл и не смог найти где бы это упоминалось. Если есть статьи, дайте ссылку. Или может я не правильно делал опыт и поведение совсем не такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2018, 08:10 |
|
||
|
Направление сортировки кластерного индекса и Range Locks
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2018, 08:53 |
|
||
|
Направление сортировки кластерного индекса и Range Locks
|
|||
|---|---|---|---|
|
#18+
aleksrov, Причем "next key" трактуется как физически, так и логически. Физичиский "next key" (который в порядке просмотра индекса) блокируется всегда. Хорошо иллюстрируется примером: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. В case 1 физический "next key" совпадает с логическим. В case 2 не совпадает. Как итог имеем ненужную блокировку на строку с k = 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2018, 11:50 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39621684&tid=1690028]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 321ms |

| 0 / 0 |
