Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Изменение типов данных в большой таблице. Подводные камни
|
|||
|---|---|---|---|
|
#18+
Привет. Хотелось бы получить подтверждение своим теоретическим предположениям у местных гуру. Дело касается в первую очередь времени выполнения. Допустим у нас есть некая таблица размером скажем с терабайт и строк эдак 15 млрд. EventDate datetime2(2), SomeID int, SomeValue double, SomeFK int, LongStrValue nvarchar(max), ShortStrValue nvarchar(20) Первые два поля = Primary Key. Какие соображения надо учитывать меняя тип данных у следущих полей? 1. EventDate datetime2(2) -> datetime2(7) Тут никаких constraint не проверяется, надо токо метаданные обновить. Но это Primary Key. И поле с фиксированной длиной. То есть надо все данные в дата файле передвигать. Так? То есть по сути самая тяжеловесная операция. Доп. вопрос: надо ли после этого индекс ребилдить или оно само в процессе дефрагментируется? Что-то мне подсказывает, то само... 2. LongStrValue nvarchar(max) -> nvarchar(200) Это тип данных с нефиксированной длиной. Метаданные обновить, но и еще проверить, влезают ли все значения в 200. Это может занять время, так? Играет ли тут какую-нить роли статистика? 3. ShortStrValue nvarchar(20) -> nvarchar(50) Вот тут я вообще никакой доп. задержки не ожидаю. Я прав? 4. SomeFK int ->bigint Можно отключить constraint временно и поменять тип данных, сэкономив время на проверке целостности. Но это поле с фикс. длиной. Будет ли операция столь же тяжеловесной как и в (1) ? Приведет ли к большей фрагментации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 18:44 |
|
||
|
Изменение типов данных в большой таблице. Подводные камни
|
|||
|---|---|---|---|
|
#18+
Glebanski, при увеличении размерности обычно не чекается при уменьшении - да. Строки, конечно, просмотром только можно проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 18:48 |
|
||
|
Изменение типов данных в большой таблице. Подводные камни
|
|||
|---|---|---|---|
|
#18+
Glebanski, Изучайте Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 19:54 |
|
||
|
Изменение типов данных в большой таблице. Подводные камни
|
|||
|---|---|---|---|
|
#18+
invm, Благодарю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 20:33 |
|
||
|
Изменение типов данных в большой таблице. Подводные камни
|
|||
|---|---|---|---|
|
#18+
Вот отличная статья на тему https://social.technet.microsoft.com/wiki/contents/articles/29228.sql-server-internals-of-a-change-of-the-size-of-a-fixed-data-type.aspx Хорошо, что в ней объяснили, а то у меня глаза на лоб когда измененные поля в конец строки переместились ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2018, 18:55 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39626380&tid=1689948]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 394ms |

| 0 / 0 |
