|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Arioch> тебе ссылку зачем дали? прочитай в ней ВТОРОЕ сообщение, а ? Прочитал. И? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:51 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhЯ не прошу так сделать, я предложил рассмотреть целесообразность этогоМеханизм есть. Нужен он в 1% частных случаев. Доп. затраты (см. ответ ДЕ) будут платить все. Накуа ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:52 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Влад, ну я как то уже с этим согласился ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:53 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh> данный вопрос должен решаться архитектором БД при создании PK-ключа Как и большинство вопросов. Собсно, если по дефолту делать DESC - найдутся те, кому будет нужен ASC. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:53 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhВлад, ну я как то уже с этим согласилсяЭто я позже прочитал :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:54 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамИ? И он, типа, думает, что я кретин, который в цитату ставит случайный кусок сообщения, а не точно выпиленную посылку, на которую и даётся ответ. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:54 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hvlad > Доп. затраты (см. ответ ДЕ) будут платить все. А вот по какой методике их бы изменить? Есть идеи? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:56 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhА вот по какой методике их бы измерить? Есть идеи? Стандартный тест на время вставки 100 миллионов записей тебе чем-то не нравится?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:01 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
hvladshaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ?Не по PK, а по "просто" индексу - нужна. Темпоральные атрибуты (названия изделий или группы, к которым они относятся; госномер автомобиля, ID его собственника, номер двигателя или даже VIN (да! иногда бывает замена всего кузова, но тачка остается после этого в эксплуатации); названия клиентов, в т.ч. введённые неправильно - их тоже надо хранить для 100% воспроизводимости старых документов при их перепечатке; некоторые реквизиты организаций, которые могут меняться, но должна сохраняться вся "история соответствий времени": ФИО руководителя или главбуха, и прочая). Обычному усеру нужна последняя версия названия (актуальная сейчас); тому, кто лезет в архив за старыми док-тами - версия атрибута, ID-которой записан в этом документе. Если ID версии получается дёрганием генератора вперёд, то надо ставить убывающий индекс. А если дёргать генератор взад, то сразу неудобно при разработке / отладке: либо пялимся на отрицательные значения либо на положительные числа типа 99999999, чтобы "не так быстро ушли в минус". Но в любом случае в индексе новые значения в индексе будут появляться "против натуральной шерсти". Например, для asc-индекса это будут 1) 999999, 2) 999998, 3) 999997 - и скорее всего при выполнении запроса с plan order'ом потребуется "прыгать назад", т.е. cluster factor там будет хреновый. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:10 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Быстренький тест набросанный на коленке, основанный на импорте данных ФИАС показал, что время вставки 1 000 000 записей в таблицу с PK DESC составила 103,5% от времени вставки в аналогичную таблицу с PK ASC. Тип PK - Int32 1 000 000 не показатель, но все-таки похоже DESC-сортировка дорогое удовольствие. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:36 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh, сравни еще время выборки из заполненной таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:40 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Не понял, 3,5% - дорогое удовольствие. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:52 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
3,5%. Я посчитал что это "дорого" за возможность индексированного поиска MAX(ID) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 15:15 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
dimitrshaposh, сравни еще время выборки из заполненной таблицыИ размеры индексов тоже стоит сравнить ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 15:31 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
>> Dimitr, Vlad Обязательно сравню, не сейчас Сорри, дела ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 15:52 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Что-то не очень сильно бросается в глаза разница между: 1) скоростью заливки данных (50 млн строк, тип id = bigint) при юзании asc vs desc индексов: DDL + add initial data Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
trace Код: plaintext 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.
2) выборкой по asc vs desc индексу (делал по три запуска в каждом случае; дифферент порогов = 1 млн, значения из середины листового уровня): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
trace Код: plaintext 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.
3) статистикой индексов (практически близнецы): Код: plaintext 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. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89.
PS. LI-V3.0.0.32323 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 15:55 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Таблоид) скоростью заливки данных (50 млн строк потому что нужен диск со скоростью примерно равное скорости RAM :D ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:04 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Ariochнужен диск со скоростью примерно равное скорости RAM :DНа этой машине хотя и хорошая дисковая, но таки до скорости RAM ей далёко. ЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:09 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Таблоид, ну так ты в своём тесте генераторы перевернул для PK по DESC индексу, так конечно большой разницы быть не должно. Сомневаюсь что ТСа это устроит. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:15 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Таблоид, а зачем же ты разные данные заливаешь в таблицы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:20 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhАктуальность получения MAX(ID) для поля PK выше чем MIN(ID), поэтому представляется целесообразным по умолчанию строить DESС-индекс для поля PK. Конец недели, может поэтому не врубаюсь, из-за чего сыр-бор? Что, есть подозрение, что max(id) вызывает полный скан индекса? Проверяем на Оракле: Код: sql 1.
В таблице больше 100млн записей. План выполнения: Код: sql 1. 2. 3.
Может, FULL SCAN (MIN/MAX) отличается чем-то от простого FULL SCAN, но время выполнения варьируется от 16 до 31 мсек. Не верю, что весь индекс сканировался. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:31 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
hvladа зачем же ты разные данные заливаешь в таблицы ?не "зачем", а "от чего": тумблер многостаночника был включён, отвлекался на всякое разное... лок-таблицы там всякие с бак-трассами какими-то... ;-) Сейчас повторю по-новой с test-dec. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:38 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
DirksDR, не надо тут Ораклом трясти. Во первых у него есть index only scan, а в FB нету. Во вторых в оракле индексы по умолчанию двунаправленные. DirksDRМожет, FULL SCAN (MIN/MAX) отличается чем-то от простого FULL SCAN должен отличаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 16:46 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ТаблоидСейчас повторю по-новой с test-dec.Заливка в пустую базу тех же 50 млн: trace: 869686 ms, 1129 read(s), 887981 write(s), 408344253 fetch(es), 151846887 mark(s) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
3124 ms, 9130 read(s), 3002993 fetch(es) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Код: plaintext 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.
Код: plaintext 1. 2. 3.
Сжимаемость в два раза хуже почему-то... листовых блоков стало 144575 против прежних 73987. А вот clustering ratio по-прежнему ОК - всего 0.01 (т.е. это означает, что при навигации для перехода к след. ключу в 99% случаев движку не придётся прыгать на другую страницу, как это было бы с длинными ключами, например; я прав в этом суждении ?) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 17:00 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ТаблоидСжимаемость в два раза хуже почему-то... листовых блоков стало 144575 против прежних 73987.Ибо вставка в конец индекса - это одно, а в начало - это другое. Смотри на "Fill distribution" у индексов ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 18:44 |
|
|
start [/forum/topic.php?fid=40&msg=39164002&tid=1562358]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
others: | 261ms |
total: | 405ms |
0 / 0 |