|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Непонятно умолчательное направление при построении индекса по PK. То есть в 9 случаях из 10 подобное поле является целочисленным и заполняется автоинкриментом генератора, поэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального. Но индекс для PK по умолчанию строиться ASC, что позволяет получать с использованием данного индекса только минимальное значение, Но не максимальное. Т.е. ALTER TABLE TEST ADD CONSTRAINT PK$TEST_ID PRIMARY KEY (ID); Здесь Select max(id) from TEST не использует индекс, разумеется Здесь Select min(id) from TEST использует индекс ALTER TABLE TEST ADD CONSTRAINT PK$TEST_ID PRIMARY KEY (ID) USING DESCENDING INDEX IX$TEST_ID; Здесь будет наблюдаться обратная ситуация. Актуальность получения MAX(ID) для поля PK выше чем MIN(ID), поэтому представляется целесообразным по умолчанию строить DESС-индекс для поля PK. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 12:38 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh Актуальность получения MAX(ID) для поля PK выше чем MIN(ID), поэтому представляется целесообразным по умолчанию строить DESС-индекс для поля PK. А как же генераторы? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 12:47 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh, все эти рассуждения чешуя. По хорошему нужны двунаправленные индексы и они должны создаваться по умолчанию. Но когда это сделают и сделают ли вообще неизвестно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 12:52 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
"А как же генераторы?" Запись может быть удалена "нужны двунаправленные индексы" Нужны, ой как нужны, но когда они появятся и появятся ли вообще? А вот до их появления можно путем изменения умолчательного поведения улучшить ситуацию Причем реализация вряд ли трудозатратна ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 12:59 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
1) max(pk) это как-то совсем не по феншую 2) desc-индексы обычно чуть медленнее asc-индексов (ибо ключ длиннее) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:00 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Shaposh! You wrote on 5 февраля 2016 г. 13:00:06: Shaposh> Непонятно умолчательное направление при построении индекса по PK. > То есть в 9 случаях из 10 подобное поле является целочисленным и заполняется автоинкриментом генератора, > поэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального. генератору похеру инкрементироваться, или декрементироваться. равно как и значению поля суррогатного ключа. инкрементируешь - твоё право. но тогда не нужно в связи с этим пытаться изменить окружающий мир, исходя из личного видения вселенской гармонии. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:03 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
О, опять "мимопроходящий умник" с бесполезными рассуждениями на философские темы. Даже боюсь спросить как много разработчиков в процентном отношении получают целочисленный первичный ключ путём уменьшения генератора... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:11 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:12 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
hvladshaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ? Для того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность. Получить её можно (и нужно) с помощью SELECT MAX(ID) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:20 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Ну мало ли задач при реализации бизнес-логики возникает. Получить последнюю актуальную вставленную запись.... Что то там с неё прочитать Мне от различных команд программистов при внедрениях просто надоело отвечать на вопрос "почему не используется индекс в запросе "SELECT MAX(ID)" И вот никто ни разу не спросил ("почему не используется индекс при SELECT MIN(ID)") Просто получать MIN(ID) действительно не нужно практически никогда MAX(ID) - иногда нужно, но вот индекс для этого не подходит Я не прошу так сделать, я предложил рассмотреть целесообразность этого ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:21 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhНужны, ой как нужны, но когда они появятся и появятся ли вообще? Когда кто-нибудь придумает алгоритм deadlock-free работы с двусвязным списком, чего за последние 30 лет никто так и не сумел. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:23 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Shaposh! You wrote on 5 февраля 2016 г. 13:26:02: Shaposh> Я не прошу так сделать, я предложил рассмотреть целесообразность этого юный наивный мечтатель Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:26 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
"Мимопроходящему умнику" - Ты для разнообразия, хоть что-нибудь адекватное по теме... Помимо своего обычного словесного поноса выдать в состоянии? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:30 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh> что-нибудь адекватное по теме... Хватит агриться уже. По теме - по умолчанию-то оно так, но вас же не заставляют, делайте DESC. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:34 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposhпоэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального Мне тоже кажется, что в большинстве (но далеко не во всех!) случаях в основном в таблице будт брать последние значения. Хотя к самим генераторам это никакого отношения не имеет! НО! Как почти всегда в данных важно не только "как чаще всег очитают", но и соотношение как часто читают/как часто пишут. Простой пример - список и массив, в список легко данные вставлять, из массива легко читать. shaposhцелесообразным по умолчанию строить DESС-индекс для поля PK. ...и вот тут засада, добавление "самого большого" значения в DESC-индекс сильно дороже, чем в ASC-индекс соотв. с добавлением "самого маленького" - наоборот http://www.sql.ru/forum/1187963/pk-indeks-ascending-ili-descending Поэтому если таблицу часто читают и намнооого реже пишут, то можно убрать PK и вместо него явно завести Unique-индекс. Но это насколько я понял на практике сродни ловле блох и очень редко будет заметно: вычитывание индекса с диска в память в любом случае намного дольше, чем поиск в памяти по "неудобному" индексу, и поэтому ускорение второго шага почти никогда ничего не даст. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:39 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустамно вас же не заставляют, делайте DESC. заставляют. Сделать руками индекс для PK невозможно. http://www.sql.ru/forum/1187963/pk-indeks-ascending-ili-descending ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:40 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Shaposh! You wrote on 5 февраля 2016 г. 13:37:48: Shaposh> "Мимопроходящему умнику" - Ты для разнообразия, хоть что-нибудь адекватное по теме... зайко, тебе ж давно уже не 20, а жить в реальном мире так и не научился... мечтай, мечтай Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:42 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Да я так и делаю. Но вопрос-то не во мне Я предположил, что изменение направления построения ключа для ПК выглядит обоснованно, ибо имеет плюсы и не имеет минусов Dimitr указал, что минусы есть - чуть меньшая производительность Этого достаточно, чтобы получить заключение - действительно, данный вопрос должен решаться архитектором БД при создании PK-ключа ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:43 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Arioch! You wrote on 5 февраля 2016 г. 13:44:09: Arioch> заставляют. Сделать руками индекс для PK невозможно. ADD CONSTRAINT ... PRIMARY KEY ... USING DESCENDING INDEX ... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:44 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Мимопроходящий, тебе ссылку зачем дали? прочитай в ней ВТОРОЕ сообщение, а ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:45 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ну или я Сибирякова не понял, странно что в той теме никто этого не упомянул ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:46 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Arioch! You wrote on 5 февраля 2016 г. 13:47:39: Arioch> тебе ссылку зачем дали?я не хожу по ссылкам. ради тебя сделал исключение. прочитал. вывод: вася, ты лошара (с) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:48 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Arioch, он говорил что в USING нельзя использовать существующий индекс, но зато создаётся новый с требуемым тебе направлением. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:49 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Arioch> Сделать руками индекс для PK невозможно. Ты бред какой-то несёшь. Код: sql 1. 2. 3.
Ку ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:50 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
YuRockДля того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность.Причём тут значение суррогатного ПК ? YuRockПолучить её можно (и нужно) с помощью SELECT MAX(ID)А я думал свежесть определяется датой, а актуальность - флагом состояния... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 13:50 |
|
Умолчательное направление при построении индекса по 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 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ТаблоидЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ? стоимость перестройки деревьев индексов при массовом добавлении новых листьев "в хвост" и "в гриву" ...а пока ты замерил скорость записи новых данных на HDD ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 19:48 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Таблоид, вопрос в том, какой процент в базе таких ID составляет от остальных ID, которые GUID, хэш, и прочее, и которым этот MAX(ID) абсолютно пофиг. Вангую в 60% (для max(id)). Собственно, подозреваю, что как раз этот max(id) чаще нужен не сам по себе, а в сочетании с group by. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 20:00 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
AriochТаблоидЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ? стоимость перестройки деревьев индексов при массовом добавлении новых листьев "в хвост" и "в гриву" ...а пока ты замерил скорость записи новых данных на HDDесли речь идёт о PK, то значения будут монотонно возрастать. И листья будут массово добавляться либо только в хвост, либо только в гриву. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 20:11 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
kdvвопрос в том, какой процент в базе таких ID составляет от остальных ID, которые GUID, хэш, и прочее, и которым этот MAX(ID) абсолютно пофиг. Вангую в 60% (для max(id)).Двунаправленный скан может быть полезным, КМК, только для данных, которые каким-то образом связаны с "осязаемыми величинами": временем (прежде всего), деньгами / количеством, скоростью, температурой и проч. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 20:19 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
hvladYuRockДля того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность.Причём тут значение суррогатного ПК ? YuRockПолучить её можно (и нужно) с помощью SELECT MAX(ID)А я думал свежесть определяется датой, а актуальность - флагом состояния... Не надо про коня. Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто. И вот плохо, когда номер последней смены не по индексу ищется. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 23:47 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Это я отвечал, когда это нужно. Не спорю, что это редкий случай, для которого можно вручную указать desc для пк. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 23:54 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
shaposh3,5%. Я посчитал что это "дорого" за возможность индексированного поиска MAX(ID) Ни в одном проекте не использовал MAX/MIN по первичному ключу. Даже не представляю, для чего это может понадобиться, кроме возможности огрести проблем в многопользовательском режиме. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2016, 00:27 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
YuRockhvladпропущено... Причём тут значение суррогатного ПК ? пропущено... А я думал свежесть определяется датой, а актуальность - флагом состояния... Не надо про коня. Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто. ... Генератор прочесть нельзя? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2016, 00:30 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ZeroMQYuRockпропущено... Не надо про коня. Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто. ... Генератор прочесть нельзя? Нет, он будет неинициализирован для конкретной торговой точки в центральной базе. ПК из двух ключей - TERMINAL_ID,ID. А процедурки работают одинаково на всех базах. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2016, 00:59 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
YuRockZeroMQпропущено... Генератор прочесть нельзя? Нет, он будет неинициализирован для конкретной торговой точки в центральной базе. ПК из двух ключей - TERMINAL_ID,ID. А процедурки работают одинаково на всех базах. Сурово как. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2016, 01:07 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
ZeroMQ >> Сурово как Нет, просто жизнь богаче наших схем ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2016, 18:57 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Таблоидесли речь идёт о PK, то значения будут монотонно возрастать. ...или убывать, смотря что в триггере напишешь. Таблоидлибо только в хвост, либо только в гриву. Угу, и если бы как-то убрать bottleneck по сбросу 15М записей на HDD (RAM disk, желательно сразу партицию в обход файловой системы), то затраты на перестройку "грив" и "хвостов" (и их разница) были бы, вероятно, заметны ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 11:19 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Yurock! You wrote on 8 февраля 2016 г. 11:48:19: Yurock> Регулярно возникают задачи, в которых необходима сквозная нумерация. в таких задачах "нумерация" не используется как РК. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 11:48 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
МимопроходящийHello, Yurock! You wrote on 8 февраля 2016 г. 11:48:19: Yurock> Регулярно возникают задачи, в которых необходима сквозная нумерация. в таких задачах "нумерация" не используется как РК. Поздравляю, в очередной раз удачно в атмосферу вбросил. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 13:13 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Hello, Yurock! You wrote on 8 февраля 2016 г. 13:18:00: YurockМП> в таких задачах "нумерация" не используется как РК. > Поздравляю, в очередной раз удачно в атмосферу вбросил.мда... если такие "самородки" проектируют БД, то комментарии излишни. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 13:19 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
Мимопроходящийесли такие "самородки" проектируют БД, то комментарии излишни. Зато потом какое пространство для творчества - "как сделать бездырочную нумерацию, если у меня PK и есть номер, а документы удаляли вразнобой полгода"... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 14:49 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
DarkMasterМимопроходящийесли такие "самородки" проектируют БД, то комментарии излишни. Зато потом какое пространство для творчества - "как сделать бездырочную нумерацию, если у меня PK и есть номер, а документы удаляли вразнобой полгода"...Не понял, о чем речь вообще, о каких документах. В моем случае этот ID в ПК - номер смены - он уникальный на торговой точке, числовой и бездырочный и никто никогда смены не удаляет, особенно вразнобой. Каждый день открывается одна смена (примерно), т.е. за всю жизнь программы в этой таблице будет максимум тысячи записей. Теперь обьясни мне, почему не использовать этот идентификатор как ключ ПК? Зачем вводить рядом такое же поле? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 16:58 |
|
Умолчательное направление при построении индекса по PK
|
|||
---|---|---|---|
#18+
юрок, ты не обижайся. ответь на пару вопросов. 1. ты самоучка? 2. как ты относишься к древней статье Толика Тенцера? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2016, 17:06 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1562358]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
107ms |
get tp. blocked users: |
2ms |
others: | 262ms |
total: | 459ms |
0 / 0 |