Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
asd24
Member

Откуда:
Сообщений: 47
Доброго времени суток, коллеги.

На нашем проекте есть большой модуль с анкетами пользователей. Основные таблицы, используемые в модуле:
dbo.WorkSheets - список всех анкет по пользователям;
dbo.WorkSheetsData - заполненные пользователями анкеты;
dbo.WorkSheetsFieldsMapping - маппинг филдов анкеты (соотношение вопросов по анкетам)

SQL:

CREATE TABLE dbo.WorkSheets(
	WorkSheetsID   INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_WORKSHEETSID PRIMARY KEY,
	WorkSheetGlobalID   INT NOT NULL CONSTRAINT FK_WORKSHEETS_WORKSHEETGLOBALID REFERENCES dbo.GlobalDirectory(WorkSheetGlobalID),
	UserID   INT NOT NULL CONSTRAINT FK_WORKSHEETS_USERID REFERENCES dbo.Users(UserID),
	CreatedDate   DATETIME NULL
	/*
	etc..
	*/
);

CREATE TABLE dbo.WorkSheetsFieldsMapping(
	WorkSheetsFieldsMappingID   INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_WORKSHEETSFIELDSMAPPINGID PRIMARY KEY,
	WorkSheetGlobalID   INT NOT NULL CONSTRAINT FK_WORKSHEETSFIELDSMAPPING_WORKSHEETGLOBALID REFERENCES dbo.GlobalDirectory(WorkSheetGlobalID),
	FieldName   NVARCHAR(255) NOT NULL,
	FieldDataType   NVARCHAR(255) NOT NULL
	/*
	etc..
	*/
);

CREATE TABLE dbo.WorkSheetsData(
	WorkSheetsDataID   INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_WORKSHEETSDATAID PRIMARY KEY,
	WorkSheetsID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSID REFERENCES dbo.WorkSheets(WorkSheetsID),
	WorkSheetsFieldsMappingID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSFIELDSMAPPINGID REFERENCES dbo.WorkSheetsFieldsMapping(WorkSheetsFieldsMappingID),
	[Value]   NVARCHAR(4000),
	CreatedDate   DATETIME NULL
	/*
	etc..
	*/
);


Пример c анкетой PersonalData для UserID = 10:
WorkSheets - одна запись для юзера UserID = 10 с WorkSheetGlobalID из основного справочника
WorkSheetsFieldsMapping - набор колонок (Имя, Фамилия, ДатаРождения и т.д. для анкеты PersonalData)
WorkSheetsData - заполненные данные по анкете (Иван, Иванов, 1988-01-01... )

Проблема следующая - у нас очень много анкет и соответственно очень-очень много данных в WorkSheetsData (сейчас ~250 миллионов). Таблица стремительно растёт и постоянно используется (создаются новые анкеты, обновляются конфигурации текущих и т.д.). В итоге WorkSheetsData стала нашим узким местом - запросы стали работать хуже.

Можно ли как-то изменить структуру хранения данных, чтобы улучшить производительность?

На проекте используется SQL Server 2014 Enterprise.

Заранее спасибо.
13 апр 17, 03:38    [20396588]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
asd24
Проблема следующая - у нас очень много анкет и соответственно очень-очень много данных в WorkSheetsData (сейчас ~250 миллионов). Таблица стремительно растёт и постоянно используется (создаются новые анкеты, обновляются конфигурации текущих и т.д.). В итоге WorkSheetsData стала нашим узким местом - запросы стали работать хуже.

Можно ли как-то изменить структуру хранения данных, чтобы улучшить производительность?

На проекте используется SQL Server 2014 Enterprise.

Заранее спасибо.

Ну, во первых, желательно бы понять что именно тормозит. И как именно тормозит.
Потому что вариантов может быть масса:
1. Просто просто добавить оперативки в сервер
2. Высадить проблемную таблицу в другую файловую группу на другой (быстрый) диск.
3. Разориться на приличный быстрый SSD и включить, наконец, BPE.
4. Секционировать проблемную таблицу, и опять же рассадить ее по разным дискам
5. Разобраться, наконец, что там со статистикой и индексами на этой таблице, и может поотключать "кебенемат" (как говорят наши сотрудники татары) лишние индексы, и автоапдейт статистики (и соответственно, апдейтить ее руками, в нужных местах)
6. Может просто индексов не хватает. Ну или лишние есть, см. 5.


В общем "у меня в подвале стук. Шой то?"
13 апр 17, 08:34    [20396751]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
Кстати, прямой и бесстыдный вопрос: Поля, содержащие внешние ключи конечно же проиндексированы?
13 апр 17, 08:58    [20396836]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
asd24
В итоге WorkSheetsData стала нашим узким местом - запросы стали работать хуже.

Можно ли как-то изменить структуру хранения данных, чтобы улучшить производительность?
Структура обычная - EAV, но для анкет по другому и не сделаешь.

Если всё правильно сделано, то от размера таблицы время выполнения запросов не зависит.

Смотрите конкретные узкие места, может, с индексами что то не так, с самими запросами, с архитектурой приложения.
13 апр 17, 09:13    [20396894]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
uaggster
Кстати, прямой и бесстыдный вопрос: Поля, содержащие внешние ключи конечно же проиндексированы?
Индексирование FK помогает одной операции - удалению.
Если у них этого нет, то можно и не делать инедксов.
13 апр 17, 09:15    [20396898]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
alexeyvg
uaggster
Кстати, прямой и бесстыдный вопрос: Поля, содержащие внешние ключи конечно же проиндексированы?
Индексирование FK помогает одной операции - удалению.
Если у них этого нет, то можно и не делать инедксов.

А апдейту - не помогает?
13 апр 17, 09:19    [20396916]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
uaggster
Потому что вариантов может быть масса:
1. Просто просто добавить оперативки в сервер
2. Высадить проблемную таблицу в другую файловую группу на другой (быстрый) диск.
3. Разориться на приличный быстрый SSD и включить, наконец, BPE.
4. Секционировать проблемную таблицу, и опять же рассадить ее по разным дискам
5. Разобраться, наконец, что там со статистикой и индексами на этой таблице, и может поотключать "кебенемат" (как говорят наши сотрудники татары) лишние индексы, и автоапдейт статистики (и соответственно, апдейтить ее руками, в нужных местах)
6. Может просто индексов не хватает. Ну или лишние есть, см. 5.
Или, что скорее всего, случайно на mouse click делается select count(*)

Нужно сначала найти узкое место.

От размера таблиц быстродействие запросов не зависит, кроме случая нехватки памяти, поиска без индексов, ну и особых случаев поиска - но какие там поиски у анкет? Работа с анкетой по ИД, и агрегированные результаты анкетирования по ИД опроса..
13 апр 17, 09:21    [20396923]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
uaggster
alexeyvg
пропущено...
Индексирование FK помогает одной операции - удалению.
Если у них этого нет, то можно и не делать инедксов.

А апдейту - не помогает?
Нет, конечно. Что это нужно проапдэйтить, что бы понадобился индекс на поле FK? Ключевое поле мастер-таблицы? :-)
13 апр 17, 09:23    [20396929]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
aleks2
Guest
uaggster
Потому что вариантов может быть масса:
1. Просто просто добавить оперативки в сервер
2. Высадить проблемную таблицу в другую файловую группу на другой (быстрый) диск.
3. Разориться на приличный быстрый SSD и включить, наконец, BPE.
4. Секционировать проблемную таблицу, и опять же рассадить ее по разным дискам
5. Разобраться, наконец, что там со статистикой и индексами на этой таблице, и может поотключать "кебенемат" (как говорят наши сотрудники татары) лишние индексы, и автоапдейт статистики (и соответственно, апдейтить ее руками, в нужных местах)
6. Может просто индексов не хватает. Ну или лишние есть, см. 5.


Моя плакаль. Какое буйство бессмыслия!

ЗЫ. Тредстартеру.

Таблица
CREATE TABLE dbo.WorkSheetsData(
	WorkSheetsDataID   INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_WORKSHEETSDATAID PRIMARY KEY,
	WorkSheetsID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSID REFERENCES dbo.WorkSheets(WorkSheetsID),
	WorkSheetsFieldsMappingID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSFIELDSMAPPINGID REFERENCES dbo.WorkSheetsFieldsMapping(WorkSheetsFieldsMappingID),
	[Value]   NVARCHAR(4000),
	CreatedDate   DATETIME NULL
	/*
	etc..
	*/
);

спроектирована бездарно. Нибось анкеты выбираются, в основном?

Кластерный индекс надо по (WorkSheetsID, [далее по фкусу, можно и WorkSheetsDataID]).
13 апр 17, 09:25    [20396932]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
alexeyvg
uaggster
пропущено...

А апдейту - не помогает?
Нет, конечно. Что это нужно проапдэйтить, что бы понадобился индекс на поле FK? Ключевое поле мастер-таблицы? :-)

Эээ...
Update a
    Set CreatedDate='20140101'
    From dbo.WorkSheets a inner join
	    dbo.WorkSheetsData b on a.WorkSheetsID=b.WorkSheetsID
Where b.[Value] like 'A%'

?
13 апр 17, 09:30    [20396949]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
aleks2
uaggster
Потому что вариантов может быть масса:
1. Просто просто добавить оперативки в сервер
2. Высадить проблемную таблицу в другую файловую группу на другой (быстрый) диск.
3. Разориться на приличный быстрый SSD и включить, наконец, BPE.
4. Секционировать проблемную таблицу, и опять же рассадить ее по разным дискам
5. Разобраться, наконец, что там со статистикой и индексами на этой таблице, и может поотключать "кебенемат" (как говорят наши сотрудники татары) лишние индексы, и автоапдейт статистики (и соответственно, апдейтить ее руками, в нужных местах)
6. Может просто индексов не хватает. Ну или лишние есть, см. 5.


Моя плакаль. Какое буйство бессмыслия!

Ыыы... А поподробнее расшифровать? :-)
13 апр 17, 09:31    [20396954]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
aleks2
Кластерный индекс надо по (WorkSheetsID, [далее по фкусу, можно и WorkSheetsDataID]).
Ну, не обязательно.
Галвное, вообще нужно смотреть выборки и делать индексы.
uaggster
Кстати, прямой и бесстыдный вопрос: Поля, содержащие внешние ключи конечно же проиндексированы?
Тут, конечно, нужно ещё учитывать, что FK в данном случае - не просто "ссылка на справочник", а запись в мастер-таблице, и очевидно, выборки нужно будет делать по нему.
Так что на все FK получается надо делать индексы.
13 апр 17, 09:36    [20396970]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
asd24
Member

Откуда:
Сообщений: 47
uaggster
Ну, во первых, желательно бы понять что именно тормозит. И как именно тормозит.

На сайте в этом модуле может быть до 200 клиентов в моменте. Кто-то обновляет свои анкеты, кто-то удаляет, кто-то создает новые.
И получается что вся нагрузка идёт на эту одну таблицу WorkSheetsData.. запросы выполняются медленее(select, update в основном) - сайт подтормаживает.

uaggster
Потому что вариантов может быть масса:
1. Просто просто добавить оперативки в сервер
2. Высадить проблемную таблицу в другую файловую группу на другой (быстрый) диск.
3. Разориться на приличный быстрый SSD и включить, наконец, BPE.
4. Секционировать проблемную таблицу, и опять же рассадить ее по разным дискам

128 GB - это мало для такой таблицы? Проблем с дисками и CPU нету.
Насколько я знаю, секционирование не даёт прироста в таких ситуациях - у нас много точечных запросов (seeks)

uaggster
5. Разобраться, наконец, что там со статистикой и индексами на этой таблице, и может поотключать "кебенемат" (как говорят наши сотрудники татары) лишние индексы, и автоапдейт статистики (и соответственно, апдейтить ее руками, в нужных местах)
6. Может просто индексов не хватает. Ну или лишние есть, см. 5.

Индексы созданы на все основные колонки, которые участвуют в JOIN + условиях WHERE.

PS как я понимаю, у нас проблема не с запросами. они работают по отдельности быстро, но когда их становится больше чем 100 одновременно, то получаем просадки
13 апр 17, 09:58    [20397066]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
asd24
128 GB - это мало для такой таблицы? Проблем с дисками и CPU нету.
У меня одна из таблиц 12 ТБ :-)
asd24
На сайте в этом модуле может быть до 200 клиентов в моменте. Кто-то обновляет свои анкеты, кто-то удаляет, кто-то создает новые.
И получается что вся нагрузка идёт на эту одну таблицу WorkSheetsData.. запросы выполняются медленее(select, update в основном) - сайт подтормаживает
Статистику собирайте, а то это беспредметно: "128 гб, 200 пользователей".
Тормозят не пользователи или сектора на диске, а выполнение запросов.

Сколько запросов в секунду? Сколько времени занимает запрос? Нет ли запросов, которые выполняются долго, и накладывают какие то мешающие другим блокировки? Как загружен ЦПУ? Какие очереди к дискам?
"Тормозит" - это конкретное долгое выполнение запроса, из за которого пользователь долго ожидает реакции на свои действия. Что это за запрос? Почему конкретно он долго выполняется?
13 апр 17, 10:06    [20397106]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Абсолютно вся инфа хранится в одном поле WorkSheetsData.Value ? Это плохая практика. Понадобятся интенсивные преобразования convert() при поиске/выборках/апдейтах, например, даты или ссылки.
Это адовые операции для сервера. Заведома безиндексные.

Я у подобных таблиц делал набор полей всех типов (строка, дата, нюмерик, целое, булеан, БЛОБ) и поле с указанием типа данных.
Всегда заранее известно, какого типа параметр. И в поиске/условиях будет фигурировать поле для нужного типа. Без преобразований.
Избыточность есть, но незначительная.
13 апр 17, 10:09    [20397134]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
asd24
Member

Откуда:
Сообщений: 47
alexeyvg
Структура обычная - EAV, но для анкет по другому и не сделаешь.

Если всё правильно сделано, то от размера таблицы время выполнения запросов не зависит.

Смотрите конкретные узкие места, может, с индексами что то не так, с самими запросами, с архитектурой приложения.


Я склоняюсь к тому, что проблема с архитектурой.
13 апр 17, 10:16    [20397173]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
asd24
Member

Откуда:
Сообщений: 47
aleks2

Таблица
CREATE TABLE dbo.WorkSheetsData(
	WorkSheetsDataID   INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_WORKSHEETSDATAID PRIMARY KEY,
	WorkSheetsID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSID REFERENCES dbo.WorkSheets(WorkSheetsID),
	WorkSheetsFieldsMappingID   INT NOT NULL CONSTRAINT FK_WORKSHEETSDATA_WORKSHEETSFIELDSMAPPINGID REFERENCES dbo.WorkSheetsFieldsMapping(WorkSheetsFieldsMappingID),
	[Value]   NVARCHAR(4000),
	CreatedDate   DATETIME NULL
	/*
	etc..
	*/
);

спроектирована бездарно. Нибось анкеты выбираются, в основном?

Кластерный индекс надо по (WorkSheetsID, [далее по фкусу, можно и WorkSheetsDataID]).

Подскажите, что не так со структурой?
Тянутся филды по анкетам пользователей.
13 апр 17, 10:19    [20397191]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
asd24
Я склоняюсь к тому, что проблема с архитектурой.
Ну, это слишком неконкретно :-)

asd24
aleks2
спроектирована бездарно. Нибось анкеты выбираются, в основном?

Кластерный индекс надо по (WorkSheetsID, [далее по фкусу, можно и WorkSheetsDataID]).

Подскажите, что не так со структурой?
Тянутся филды по анкетам пользователей.

Имеется в виду, что когда вы берёте ответы по анкете из WorkSheetsData, то т.к. кластерный индекс не по WorkSheetsID, сервер делает лукап, доставая записи по одной уже по WorkSheetsDataID.
Логично делать кластерный индекс по WorkSheetsID, что бы они лежали вместе, и сразу же читались по запросу по WorkSheetsID
13 апр 17, 10:38    [20397283]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
asd24,
Проверьте, как именно приложение работает с базой. Может, дело в блокировках.
13 апр 17, 10:45    [20397326]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
uaggster
Member

Откуда:
Сообщений: 1059
asd24
128 GB - это мало для такой таблицы?

Да откуда ж я знаю, много это или мало?
Может таблица пару терабайт весит, а обращение идет параллельно хаотически в разные части таблицы + периодические сканы, например.

asd24

Проблем с дисками и CPU нету.

PS как я понимаю, у нас проблема не с запросами. они работают по отдельности быстро, но когда их становится больше чем 100 одновременно, то получаем просадки

Это как раз говорит, о том, что дисковая подсистема может являться узким местом.
Очередь к диску - какая в это время? (А диски, конечно, SAS, а не SATA, да?)
Если чтения - случайные, а таблица таки в память - не лезет, то и читаться данные будут случайно с дисков. Что тождественно равно очень медленно. У вас же не SSD диски?

asd24
Насколько я знаю, секционирование не даёт прироста в таких ситуациях - у нас много точечных запросов (seeks)

Это почему ж это не дает?
Разрезали таблицу на несколько секций, положили секции на разные диски. Индексы выровняли, то, сё.
Как минимум при чтении будет дергаться отдельная секция, а не вся таблица.
И параллельные чтения из разных участков таблицы не будут друг другу мешать.

Кто ж знает, что что у вас узкое место?

asd24
Индексы созданы на все основные колонки, которые участвуют в JOIN + условиях WHERE.

Ну для начала прогоните через Тюннинг адвайзер рабочий трейс, и посмотрите, чего он скажет.

asd24
PS как я понимаю, у нас проблема не с запросами. они работают по отдельности быстро, но когда их становится больше чем 100 одновременно, то получаем просадки

Ну или лочат они друг друга.
Где-нибудь индекса не хватает - и понеслось.
13 апр 17, 11:09    [20397489]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
uaggster
asd24
Насколько я знаю, секционирование не даёт прироста в таких ситуациях - у нас много точечных запросов (seeks)

Это почему ж это не дает?
Разрезали таблицу на несколько секций, положили секции на разные диски. Индексы выровняли, то, сё.
Как минимум при чтении будет дергаться отдельная секция, а не вся таблица.
И параллельные чтения из разных участков таблицы не будут друг другу мешать.
Это как то нестрого - "дёргаться", "мешать"...
Не вижу причин, по которым секционирование может привести к ускорению, при прочих равных.
Вот к замедлению, для этой модели данных, приведёт очень даже хорошо.

На диске лежат данные в секторах, сервер их читает в зависимости от условий, и неважно, есть там какие то секции, или нет.
Разве что поиск по диапазону кластерного индекса может превратиться в скан всей таблицы, и секционирование превратило бы его в скан секции. Но это особый случай, а уж в данной модели вообще неприменим.
13 апр 17, 11:15    [20397542]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Наверно это поле Value еще и индексировано ?
Индекс по такому полю nvarchar(4000) это тоже адовая штука. Пользы от него мало, а размер индекса огромный.
13 апр 17, 11:30    [20397666]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
LSV,

автор
Индекс по такому полю nvarchar(4000) это тоже адовая штука. Пользы от него мало, а размер индекса огромный.

ммм? 449 символов ориентировочно на если одно поле
13 апр 17, 12:00    [20397801]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
TaPaK
LSV,

автор
Индекс по такому полю nvarchar(4000) это тоже адовая штука. Пользы от него мало, а размер индекса огромный.

ммм? 449 символов ориентировочно на если одно поле
Ну в индексе будет 900. Ибо Нварчар.
ЕАВ с единым полем для любых данных - очень плохое решение.
13 апр 17, 12:23    [20397916]     Ответить | Цитировать Сообщить модератору
 Re: Помогите поправить структуру таблиц чтобы улучшить производителость  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
LSV,
автор
Ну в индексе будет 900. Ибо Нварчар.

что?
13 апр 17, 12:28    [20397932]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить