Эффекты с большими большими эффектами стола

Question

Я унаследовал базу данных (не все мы просто любим это), и таблица вышла из-под контроля.

База данных составляет более 50 ГБ. Я сделал дефрагментацию, а также переиндексацию, но это не помогло. Проблема в том, что таблица имеет 236 столбцов и около 23000 строк. И нет, это не опечатка!

Единственное решение, которое я вижу, это разбить стол. Приложение .Net находится в нашей интрасети, и я оптимизировал каждый кусок кода, который он содержит, а также хранимые процедуры.

Таблица содержит информацию, такую ​​как TempHigh, TempLow и TempMed. Высокий, Низкий и Мед повторяются по всему столу для других факторов. Таким образом, каждый High, Low и Med станут собственной таблицей с внешним ключом, указывающим на родительскую таблицу.

Это создаст много СОБЫТИЙ при доступе к данным и их обновлении.

Это единственный способ увидеть, что может решить проблему.

Мой вопрос: не могу ли я лучше решить эту проблему?

Любые предложения приветствуются.

Спасибо !!!

EDIT

Просто чтобы прояснить, я запустить дефрагментацию в базе данных, а также переиндексации. У меня был монитор производительности, открытый также на веб-сервере и серверах db.

Спасибо за комментарии. Я постараюсь ответить на ваши вопросы. Во-первых, я скопировал базу данных в мою среду разработки .Net, и она медленная, даже когда я только что зашел в систему. И перенесла приложение .Net на тот же сервер, что и сервер sql, для проверки проблем подключения. Те же проблемы. Это система транзакций (OLTP). Некоторые столбцы я уже переместил в свои собственные таблицы, поскольку они повторяли себя и вместо них новый столбец с внешним ключом (без ограничения). Нет изображений, просто данных.

Вот спецификации таблицы:

TableName SchemaName RowCounts TotalSpaceKB UsedSpaceKB UnusedSpaceKB 
MyTable   dbo  22904  45192   45160  32 

Answer 1

я с видом лучший способ решить эту проблему?

Да:

• Профиль приложения (исходный код, а не SQL), чтобы гарантировать, что доступ к БД медленная часть
• Run SQL прослеживает, чтобы определить наихудший выполнения запросов и работать с хороший администратор базы данных для определения возможных оптимизаций
• Убедитесь, что все статистические данные являются актуальными (по крайней мере, ежедневно).
• Не угадывайте - используйте твердые факты для выявления узких мест производительности.
• Убедитесь, что у вас есть соответствующие индексы для наиболее распространенных запросов.
• Не предполагайте, что разрушение стола ускорит процесс. Фактически это может сделать вещи медленнее, если вы постоянно присоединяетесь к нескольким таблицам, которые равны 1: 1.

Я видел базы данных, которые терабайт в размере, который до сих пор выполняет хорошо (добавление/uptating тысячи записей в день). Ключ определяет самые медленные операции и добавляет/обновляет индексы для их оптимизации.