2017-10-12 11 views
0

intカラムの最後の桁のインデックスをMySQLで作成することはできますか?私は、クエリ時間を最適化するためのpostIdの最後の数字のインデックスを作成しようとしているint型の列INTインデックスの最後の桁に基づくMySQLインデックス

CREATE TABLE partition_test(
    textfiled INT, 
    cltext TEXT, 
    reindexedAt TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    indexedAt TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    status TINYINT(2), 
    postId INT) 
PARTITION BY HASH(MOD(postId, 10)) 
PARTITIONS 10; 

の最後の数字に基づいて

このanswerに基づいて、私が作成したパーティション。 postIdでこれを行う方法や単純なインデックスで十分ですか?

いくつかは、試行に失敗した:

CREATE INDEX postLastDigit USING HASH ON partition_test (MOD(postId, 10)); 
(1064, u"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'MOD(postId, 10))' at line 1") 

CREATE INDEX postLastDigit ON partition_test (MOD(postId, 10)); 
(1064, u"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'MOD(postId, 10))' at line 1") 

UPDATE: テーブル以上100M行を有します。

1)

SELECT cltext FROM partition_tables 
    WHERE postId in (<INT>, <INT>) 
    AND status IS NOT NULL 

2)

SELECT cltext FROM partition_tables 
    WHERE postId in (<INT>, <INT>) 
    AND status IS NOT NULL 
    AND reindexedAt BETWEEN (<DATE>, <DATE>) 

MariaDBバージョン:10.1.23-MariaDB-9 + deb9u1

私の目標は、のようなクエリを最適化することです

+0

これは悪い考えです。さらに、本質的に*ランダムなパーティショニングは何も改善しません。サーバーがすべてのパーティションを強制的に検索するため、パフォーマンスが低下します*。 –

答えて

1

あなたの質問にとタグを付けました0およびmysql。最新のバージョンのMariaDBを使用している場合は、生成された列をインデックスに使用できます。 MySQLを使用している場合は、MySQLバージョンが5.7以上であれば同じことができます。

より低いバージョンのMySQLを使用している場合は、各行に最後の数字postIdを保存する追加の列をテーブルに作成し、その列をインデックス/パーティションに使用することができます。

これは、アプリケーションコードの変更が最小限であることを意味します。挿入または更新する前に、最初にpostIdの最後の桁を取得し、もう1つのフィールドを挿入/更新します。代わりに、最終的にトリガーを使用してその追加の列を自動的に埋めることができます。

+0

私はこの代替手段を避けようとしていました。私は他の可能な答えのためにしばらく待つでしょう、そうでなければ私はあなたを受け入れます。 tnx Binarus –

+1

ありがとう!私は過去に同じことをしてきました... – Binarus

+2

@SimakisPanagiotis:生成された列([Generated(Virtual and Persistent)Columns](https://mariadb.com/kb/en/library/generated-columns)を作成できます。 /))、それにインデックスを付けます。 – wchiquito

0

仮想列を使用します。 MariaDB 10.2で、あなたはこの

CREATE TABLE t (
    num int, 
    last_digit int(1) AS (num % 10) VIRTUAL, 
    KEY index_last_digit (last_digit) 
) 

その後、あなたはすなわちSELECT ... WHERE last_digit = 1

MariaDBの古いバージョンでは

、5.2に、クエリでlast_digit使用することができるように、virtual aka generated columnにインデックスを作成することができます10.1の場合、非永続生成列は索引付けできないため、PERSISTENT属性をVIRTUALではなく指定する必要があります。

1

どのようなクエリを高速化しようとしていますか?テーブルにインデックスがない場合、クエリはすべてテーブルをスキャンする必要があります!スピードが必要な場合は、まずインデックス作成を検討してください。

クエリがSELECT ... WHERE post_id = 123の場合、パーティショニングによって約10倍の速さで実行される可能性があります。しかし、INDEX(post_id)は、パーティション化の有無に関わらず、何百回も高速に実行されます。

SELECTsを提供して、スピードアップを図ってください。

(あなただけのパーティショニングで遊んでいる場合はOK、他の人はあなたに生きた答えを与えている。)

「パーティションの刈り込みは」剪定列で始まる適切なインデックスよりもめったに高速です。

指定したハッシュの問題を解決した後で、クエリを使用するよりもインデックスを使用するよりも速いかどうかを報告してください。たとえインデックスにぴったりだとしても、パーティション化が速く実行されず、少し遅く実行されることもあります。

+0

このようなランダムなパーティショニングはおそらく、クエリーを10倍速く実行することになります。 –

関連する問題