Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
25.08.2008, 07:46
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Верно ли то что при замене первичного ключа с BigInt на Int производительность вырастит в 2 раза? На сколько полохо использовать VarChar в первичном ключе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.08.2008, 18:58
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Производительность не вырастет в 2 раза, скорее даже упадет. Будет хуже примерно. Производительность поиска по CHAR равна поиску по INT * 2 в степени N (число символов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2008, 08:03
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
чя321Производительность не вырастет в 2 раза, скорее даже упадет. Будет хуже примерно. Производительность поиска по CHAR равна поиску по INT * 2 в степени N (число символов) А можно это все обосновать? Особенно про int и BigInt. По идее размер поля меньше, место для индекса тоже меньше соотвественно читать с диска тоже прихотися меньше? или я чегото упустил? В документации приводится такая формула которая считает необходимое место для индекса. (средний размер ключа индекса + 9) * количество строк * 2 Разрыв конечно не в 2 раза, но приемущество int явное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2008, 10:02
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Просто любопытно, а для какой цели нужен ключ типа VARCHAR, почему нельзя, например, просто построить индекс по VARCHAR, а ключ использовать "обычный" INT или типа того. Хотелось бы услышать обоснование, если не сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2008, 14:57
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Vladimir KiselevПросто любопытно, а для какой цели нужен ключ типа VARCHAR, почему нельзя, например, просто построить индекс по VARCHAR, а ключ использовать "обычный" INT или типа того. Хотелось бы услышать обоснование, если не сложно. Ну это нужно было бы спросить у предыдущих разработчиков, которых сейчас нету. :) Менять же структуру мне ни кто не даст. Да и поздно уже, слишком все завязано. Я просто ради интереса интересуюсь во сколько бы мы выиграли в производительности, используя "Нормальные" ключи. Ну и для будущих проектов думаю пригодится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.08.2008, 18:10
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Как то видел ключи типа DECIMAL, видно переносили с DBF, да так и оставили, тяжёлое наследство прошлого. Благо хоть мы своё пишем, не удивляемся что и как. Ключи типа VARCHAR, наверное это еще та песня.. благо никогда не пробовал ) Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.08.2008, 08:07
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
BIGInt 8 байт INT 4 байта Грубо говоря Операция сравнения на 32-bit архитектуре 2 такта для BIGINT и 1 такт для INT. Правда это сущие копейки, на которые можно не обращать внимания... То что поиск по CHAR есть поиск по INT*2(n) в институте было доказательство, сейчас уже и не вспомню. Возможо если покопаться у Кнут'a можно найти... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.08.2008, 13:36
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
olzhasЯ просто ради интереса интересуюсь во сколько бы мы выиграли в производительности, используя "Нормальные" ключи. Ну и для будущих проектов думаю пригодится. На самом-то деле, на этот конкретный вопрос только вы сами и можете дать ответ. Сделайте копии таблиц с оригинальной и модифицированой структурой, перепишите интересующие запросы и прогоните бенчмарки. Я думаю, двух-трёх таблиц с двумя-тремя запросами может хватить для удовлетворения любопытства. (Сравнивать лучше копию с оригинальной структурой с копией с модифицированной, а не оригинал с копией с модифицированной, чтобы не влияла кластеризация с фрагментацией). Ширина ключа, конечно, влияет, но таблицы-то не только из ключей состоят. Для достаточно широкой таблицы разница может оказаться невелика. Умозрительным рассуждениям грош цена без конкретных тестов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.10.2008, 10:10
|
|||
|---|---|---|---|
|
|||
Primary Key Int vs BigInt |
|||
|
#18+
Провел я тесты. Для интереса взял 4 поля (int,bigint,char(8),varchar(8)), создал на каждое поле по индексу. Заполнил данными от 1 до 500000. На всякий случай реорганизовал. Посчитал статистику. Вот какие результаты Код: plaintext 1. 2. 3. Размеры объектов в страницах по 4кб Код: plaintext 1. 2. 3. Какие выводы. Процессорное время на сканирование индекса у всех практически одинаковое, поэтому основное влияние на производительность влияет размер поля и соответственно от него размер индекса. Использовать char очень даже можно. Все зависит от размера поля. VarChar стоит дороже так как он добавляет конец строки. Однако если сравнивать varchar(30) и char(30) (при тоже заполняемости от 1 до 500000) то varchar выигрывает. все это относится к полному сканированию индеска, если использовать предикат то разницы практически никакой. т.к. читаются только несколько страниц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=43&mobile=1&tid=1603654]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
62ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 393ms |
| 0 / 0 |
