タグ付けされた質問 「index」

テーブルが1つあるとしましょう CREATE TABLE Ticket ( TicketId int NOT NULL, InsertDateTime datetime NOT NULL, SiteId int NOT NULL, StatusId tinyint NOT NULL, AssignedId int NULL, ReportedById int NOT NULL, CategoryId int NULL ); この例TicketIdでは主キーです。 ユーザーがこのテーブルに対して「部分的にアドホック」なクエリを作成できるようにしたい。クエリのいくつかの部分が常に修正されるので、私は部分的に言います： クエリは常に範囲フィルターを実行します InsertDateTime クエリは常に ORDER BY InsertDateTime DESC クエリは結果をページングします ユーザーは、オプションで他の列をフィルターに掛けることができます。フィルターは、なし、1つ、または多くでフィルターできます。そして、各列に対して、ユーザーは分離として適用される値のセットから選択できます。例えば： SELECT TicketId FROM ( SELECT TicketId, ROW_NUMBER() …

9 sql-server  index 

テーブルにインデックスを追加すると検索が高速になり、挿入が遅くなるが、テーブルが大きい場合に限られると多くのリソースが見つかりました。これにより、設計上の決定であるトレードオフが生じますが、インデックスの使用が不合理になる前に、おおよそのテーブルサイズが必要です。（たとえば、10行はおそらくその制限をはるかに下回ります） この制限がどこにあるか、または私を正しい方向に向けるリソースを知っている人はいますか？

9 sql-server  index 

私のサーバーが今日クラッシュしました。これは、INNODBテーブルの1つでテーブルの同時切り捨てコマンドが原因で発生したと思います。サーバーを再起動できますが、起動後、SQLコマンドを発行しようとするたびに、次のエラーが発生します。 ERROR 2006 (HY000): MySQL server has gone away これはログで起こったことです： 121206 01:11:12 mysqld restarted 121206 1:11:13 InnoDB: Started; log sequence number 275 559321759 InnoDB: !!! innodb_force_recovery is set to 1 !!! 121206 1:11:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.95-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution InnoDB: Error: trying to …

9 mysql  innodb  corruption  index  crash 

MS Accessからインポートされたレガシーデータベースを使用しています。MS Access> SQL Serverのアップグレード中に作成された、クラスター化されていない一意の主キーを持つ約20のテーブルがあります。 これらのテーブルの多くには、主キーの複製である一意の非クラスター化インデックスもあります。 私はこれを片付けようとしています。 しかし、主キーをクラスター化インデックスとして再作成した後、外部キーを再構築しようとすると、外部キーが（重複していた）古い重複インデックスを参照しています。 重複したインデックスを削除できないため、これを知っています。 SQL Serverでは、主キーが存在する場合は常にそれを選択すると思います。SQL Serverには、一意のインデックスと主キーの間で選択する方法がありますか？ 問題を再現するには（SQL Server 2008 R2の場合）： IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Child') DROP TABLE Child GO IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Parent') DROP TABLE Parent GO -- Create the parent table CREATE …

9 sql-server  index  sql-server-2008-r2  primary-key 

FILL FACTOR、ページ、インデックス構造を理解しているため、100％FILL FACTORがまれなベストプラクティスである理由を理解しています。それでは、なぜデフォルトで0（または100％）になっているのですか？なぜ90または95ではないのですか？ 行方不明のものはありますか？

9 sql-server  index  best-practices  fill-factor 

唯一の違いは ALTER INDEX [index_name] on [object_name] REBUILD with (ONLINE=OFF, FILLFACTOR=90) そして DBCC DBREINDEX([dbname], 90) DBCCコマンドがデータベース内のすべてのテーブルのすべてのインデックスのインデックスを再作成することだけですか？

9 sql-server  index-tuning  index 

クエリの実行に非常に長い時間（15秒以上）を要するクエリがあり、データセットが大きくなるにつれて、時間の経過とともに悪化します。私は過去にこれを最適化し、インデックス、コードレベルの並べ替え、その他の最適化を追加しましたが、さらに改良する必要があります。 SELECT sounds.*, avg(ratings.rating) AS avg_rating, count(ratings.rating) AS votes FROM `sounds` INNER JOIN ratings ON sounds.id = ratings.rateable_id WHERE (ratings.rateable_type = 'Sound' AND sounds.blacklisted = false AND sounds.ready_for_deployment = true AND sounds.deployed = true AND sounds.type = "Sound" AND sounds.created_at > "2011-03-26 21:25:49") GROUP BY ratings.rateable_id クエリの目的はsound id、最新のリリースされたサウンドのと平均評価を取得することです。約1500の音と200万の評価があります。 私はいくつかの指標を持っています sounds …

9 mysql  performance  index  optimization 

現在、SQL Server 2005データベースのすべてのテーブルに対して、一度に1つのテーブルに対してDBCC INDEXDEFRAGを実行するスクリプトを実行しています。スペースの制約と稼働時間の要件により、INDEXDEFRAGの代わりにDBCC DBREINDEXを使用することはできません。 特定のテーブルが最適化されるまでに長い時間がかかることに気づきました。たとえば、 "sys.dm_exec_requests"動的管理ビューを調べると、table_idが829610394であるテーブルのクラスター化インデックスで、次のINDEXDEFRAGが現在削除されていることがわかります。 DBCC INDEXDEFRAG（0、829610394、1） デフラグプロセスが完了するまでにはかなりの時間がかかることは承知しています。現在実行中のスクリプトが最終的にすべてのテーブルを最適化するという事実は別として、現在のコマンドの実行中に別のテーブルのクラスター化インデックスで別のDBCC INDEXDEFRAGを手動で実行することに害はありますか？これを行うと、両方のテーブルが実際に同時に最適化されますか？

9 sql-server  sql-server-2005  index  dbcc 

インデックスの「パディング」の量をどのようにして知ることができますか？

9 sql-server-2008  index  optimization  index-tuning  fill-factor 

以前は、クラスター化インデックスを（常に）エンゲージする/回避するかどうかについての議論/ディスカッションは決定的ではありませんでした。 まあ、私はそれらが時々適切な特定の目的とコンテキストで使用されることを理解しました。 SQL Azureデータベースのクラスター化インデックスの要件： 「SQL Azureはクラスター化インデックスのないテーブルをサポートしていません。テーブルにはクラスター化インデックスが必要です。クラスター化制約なしでテーブルを作成する場合、テーブルで挿入操作を許可する前にクラスター化インデックスを作成する必要があります。」 以前の結論、根拠、および説明には適合しません。 例外なくクラスタ化インデックスのユビキタス性を厳密に課すという、これまでの説明から逃した理論的根拠は何ですか？

9 sql-server  database-design  azure-sql-database  index 

以下は、約10,000,000行のデータを持つ私のテーブルです CREATE TABLE `votes` ( `subject_name` varchar(32) COLLATE utf8_unicode_ci NOT NULL, `subject_id` int(11) NOT NULL, `voter_id` int(11) NOT NULL, `rate` int(11) NOT NULL, `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`subject_name`,`subject_id`,`voter_id`), KEY `IDX_518B7ACFEBB4B8AD` (`voter_id`), KEY `subject_timestamp` (`subject_name`,`subject_id`,`updated_at`), KEY `voter_timestamp` (`voter_id`,`updated_at`), CONSTRAINT `FK_518B7ACFEBB4B8AD` FOREIGN KEY (`voter_id`) REFERENCES `users` (`id`) ) …

9 mysql  index  order-by  mysql-5.7 

より大きなクエリの一部であるこの（サブ）クエリを改善しようとしています。 select SUM(isnull(IP.Q, 0)) as Q, IP.OPID from IP inner join I on I.ID = IP.IID where IP.Deleted=0 and (I.Status > 0 AND I.Status <= 19) group by IP.OPID Sentry Plan Explorerは、上記のクエリによって実行された、テーブルdbo。[I]の比較的コストのかかるキールックアップを指摘しました。 テーブルdbo.I CREATE TABLE [dbo].[I] ( [ID] UNIQUEIDENTIFIER NOT NULL, [OID] UNIQUEIDENTIFIER NOT NULL, [] UNIQUEIDENTIFIER NOT NULL, [] …

9 sql-server  sql-server-2008-r2  index  index-tuning  index-design 

以下のこの質問の内容を自分の状況に適用しようとしていますが、可能であれば、演算子Hash Match（Inner Join）をどのようにして取り除くことができるのか、少し混乱しています。 SQL Serverクエリのパフォーマンス-ハッシュマッチ（内部結合）の必要性の排除 私は10％の費用に気づき、それを減らすことができるかどうか疑問に思っていました。以下のクエリプランを参照してください。 この作業は、今日調整しなければならなかったクエリサッドから来ています。 SELECT c.AccountCode, MIN(d.CustomerSID) FROM Stage.Customer c INNER JOIN Dimensions.Customer d ON c.Email = d.Email OR ( c.HomePostCode = d.HomePostCode AND c.StrSurname = d.strSurname ) GROUP BY c.AccountCode これらのインデックスを追加した後： --------------------------------------------------------------------- -- Create the indexes --------------------------------------------------------------------- CREATE NONCLUSTERED INDEX IDX_Stage_Customer_HOME_SURNAME_INCL ON Stage.Customer(HomePostCode ,strSurname) INCLUDE (AccountCode) …

9 sql-server  sql-server-2014  index  query-performance  execution-plan 

主キーを持ついくつかのテーブルがあるとします。例： CREATE TABLE Customers ( CustomerID int NOT NULL PRIMARY KEY, FirstName nvarchar(50), LastName nvarchar(50), Address nvarchar(200), Email nvarchar(260) --... ) に一意の主キーがありCustomerIDます。 伝統的に私はいくつかの追加のカバーするインデックスが必要になるかもしれません。たとえば、CustomerIDまたはのいずれかでユーザーをすばやく見つけるにはEmail： CREATE INDEX IX_Customers_CustomerIDEmail ON Customers ( CustomerID, Email ) そして、これらは私が何十年もの間作成してきた種類のインデックスです。 一意である必要はありませんが、実際には インデックス自体は、テーブルスキャンを回避するために存在します。これは、パフォーマンスを向上させるためのカバリングインデックスです（一意性を強制するための制約としてインデックスはありません）。 今日私はちょっとした情報を思い出しました-SQL Serverは次の事実を利用できます： 列に外部キー制約があります 列には一意のインデックスがあります 制約は信頼されています クエリの実行を最適化するのに役立ちます。実際、SQL Serverインデックスデザインガイドから： データが一意であり、一意性を適用したい場合は、列の同じ組み合わせで一意でないインデックスの代わりに一意のインデックスを作成すると、クエリオプティマイザーに追加情報が提供され、より効率的な実行プランを作成できます。この場合は、一意のインデックスを作成すること（できればUNIQUE制約を作成すること）をお勧めします。 私の複数列インデックスに主キーが含まれているとすると、この複合インデックスは事実上一意になります。挿入や更新のたびにSQL Serverで強制する必要があるのは、特に制約ではありません。しかし、実際には、この非クラスター化インデックスは一意です。 このデファクトユニークインデックスを実際にユニークであるとマークすることに何か利点はありますか？ CREATE UNIQUE INDEX IX_Customers_CustomerIDEmail …

9 sql-server  index 

大きなデータがあり、一度に選択するデータの間隔が小さいので、選択は常に順序どおりになります。私はそのような目的をターゲットにしたMySQLの部分インデックスのようなPostgreSQLを実装しようとしています。部分一意制約が必要な制約と同じかどうかはわかりません。 PostgreSQL 9.4のコード CREATE UNIQUE INDEX dir_events ON events (measurement_id) USING btree (eventBody) WHERE is_active; MySQLでのypercubeの部分インデックスの試行 CREATE UNIQUE INDEX dir_events [index_type] -- TODO what here? ON events (measurement_id, is_active) [index_type] -- TODO what here? MySQL 5.5などでPostgreSQLのような部分インデックスをどのように作成できますか？

9 mysql  index