Table and Index Partitioning
I am planning to use table partitioning for one of my existing databases. All the tables in the database have a clustered index and a non-unique non-clustered index. The non-unique non-clustered index is built on the column which I would like to use as the partition column. The partition column is not part of the Primary Key or clustered index. I am using SQL Server 2016 SP1.
I came across these points while reading, "Partitioned Table and Index Strategies Using SQL Server 2008"
Are these points still applicable to SQL Server 2016 SP1?
Because, when I used the Create Partition wizard, it did not convert the primary key into a non-clustered index and add a clustered index for the partition column.
In a partitioned table, the partition column must be a part of:
The clustered index key.
The primary key.
Unique index and uniqueness constraint keys.
There are also some important requirements for indexes during a SWITCH operation:
All indexes must be aligned.
No foreign keys can reference the partitioned table.
All the tabled I want to partition have foreign keys as well. I have to perform SWITCH operation. Are there any workarounds to perform SWITCH while keeping the foreign keys?
Filtered Index I have to purge the database based on one column (partitioning column) and another column (UserId) to filter data. For example: get 7 days worth of data for UserId 1. The database can have data for up to 100 users. There is already non-clustered index created on UserId but the query performance is poor. Please suggest whether creating a secondary non-clustered filtered index on the UserId column would improve query performance.
Related
In MySql, if no primary key is defined for a table, MySQL associates a default clustered index with it which functions like a primary key.
What is the case with Oracle table having no primary key ?
MySQL (or rather innodb, which is the storage engine) does not store data the way Oracle normally does.
in MySQL (innodb), data is always stored in what is called a "clustered index". Even though it is called an index, all the data is stored there, not just the indexed columns. The data is stored in the order of the indexed column(s). If there is no appropriate primary or unique key, a synthetic key is used.
in the Oracle database, by default a table is stored as a heap, meaning rows are not stored in any particular order. Heap tables can exist without an index of any kind.
Oracle allows us to define index organized tables which work like the MySQL tables, but they must have a primary key.
So bottom line, without a primary (or non-null unique) key, the only way to uniquely identify a row in an Oracle heap table is the ROWID pseudocolumn. However, an index on ROWID is not allowed.
In Oracle nothing happens with a table with no primary key. There's no key or index created automatically.
How MySQL create index for a partition table, Example if I create 5 hash by ID partitions:
Create 1 global index for all data and 5 partitions will use this index
Create 5 partitioned index with subdata in 5 partitioned tables
Create 5 index with all data in 5 partitioned tables
Thanks
There is no "global" index for a partitioned table in MySQL.
The only indexes you can put on a partitioned table ends up being separate indexes on each partition. Each partition is effectively an independent table.
HASH partitioning is virtually useless; do you have a particular use for which you think it might be beneficial?
Addenda...
The size of the index is similar to that of a table.
Since there are no "global" indexes, you cannot have a UNIQUE key unless it includes the column(s) of the "partition key". Nor can you use FOREIGN KEYs.
There is no type of index that spans more than one table.
Partitioned table in Mysql has only local indexes support.
What does that mean? Every partition of the table stores its own B-Tree for the indexes. This can slow down the process of search if you don't have partition key as part of the index. Also for unique key constraint, you need to add partition key as part of the unique key.
Compared to Mysql, Oracle has concept of Global indexes as well. Global Indexes are very hard to manage.
I am not too sure How helpful Mysql partitions would be if it has ignored Global indexes.
Aside from the convenient auto-increment and UNIQUE features, does the PK actually speed up the index?
Will the speed be the same whether it's a non-PKed indexed INT or PKed (same column, two different tests)? If I had the same column on the same table on the same system, will it be faster if a UNIQUE INT column with an index also has PK enabled? Does PK make the index it coexists with faster?
Please, actual results only with system stats if you could be so kind.
The primary key for a table represents the column or set of columns that you use in your most vital queries. It has an associated index, for fast query performance. Query performance benefits from the NOT NULL optimization, because it cannot include any NULL values. With the InnoDB storage engine, the table data is physically organized to do ultra-fast lookups and sorts based on the primary key column or columns.
If your table is big and important, but does not have an obvious column or set of columns to use as a primary key, you might create a separate column with auto-increment values to use as the primary key. These unique IDs can serve as pointers to corresponding rows in other tables when you join tables using foreign keys.
Also refer the following locations : http://www.dbasquare.com/2012/04/04/how-important-a-primary-key-can-be-for-mysql-performance/ and http://www.w3schools.com/sql/sql_primarykey.asp
Rows in a base table are uniquely identified by the value of the primary key defined for the table. The primary key for a table is composed of the values of one or more columns.
Primary keys are automatically indexed to facilitate effective information retrieval.
The primary key index is the most effective access path for the table.
Other columns or combinations of columns may be defined as a secondary index to improve performance in data retrieval. Secondary indexes are defined on a table after it has been created (using the CREATE INDEX statement).
An example of when a secondary index may be useful is when a search is regularly performed on a non-keyed column in a table with many rows, defining an index on the column may speed up the search. The search result is not affected by the index but the speed of the search is optimized.
It should be noted, however, that indexes create an overhead for update, delete and insert operations because the index must also be updated.
Indexes are internal structures which cannot be explicitly accessed by the user once created. An index will be used if the internal query optimization process determines it will improve the efficiency of a search.
SQL queries are automatically optimized when they are internally prepared for execution. The optimization process determines the most effective way to execute each query, which may or may not involve using an applicable index.
Folks, I would like to understand the answer for the following questions:
Can I have a primary key without clustered index ? ( I am aware that when we create primary key constraint on a column, it by default creates a clustered index. So in that case, how should I deactivate clustered index ?)
Can I have a clustered index with multiple columns together ? (Like in non-clustered where I can join different columns for a single non-clustered index).
(This answer is for SQL Server 2005+ only. I know nothing about MySQL.)
Can I have a primary key without clustered index?
Yes. As you mentioned, a primary key constraint is backed by a clustered index by default. You can tell SQL Server to back the constraint with a nonclustered index by declaring the constraint as follows:
ALTER TABLE MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED(Col1);
Can I have a clustered index with multiple columns together ? (Like in non-clustered where I can join different columns for a single non-clustered index).
Yes, you can define an index with more than one column in the index key. It's really no different than a nonclustered index.
CREATE UNIQUE CLUSTERED INDEX IX_MyTable_Clus
ON MyTable(Col1, Col2, Col3);
References: ALTER TABLE, CREATE INDEX
MySQL and SQL-SERVER are different RDBMS. They have different capabilities and different syntax.
When using InnoDB, MySQL always makes the PK the clustered index.
SQL-SERVER, however, will let you create a PK without the CLUSTERED keyword, and let you use it within another index instead.
In both cases, PrimaryKeys and Indexes (clustered or not) can cover multiple fields.
I am new to indexing and gone through the basics of indexing. I can find a default clustered index for the primary key constraint within the indexes part of the corresponding table, but after creating a foreign key constraint i can't find any.
Now i've a requirement in which indexing should be implemented to improve performance. I've read about indexing the foreign key in order to improve the performance of a JOIN result.
Do i need to add the foreign key column to an additional non-clustered index or the foreign key has a default indexing?
How can i effectively implement indexing if my SQL table structure is as follows and i've a JOIN query with WHERE clause using t1_col3
table1 table2
------ ------
t1_col1(pk) t2_col1(pk)
t1_col2 t2_col2
t1_col3 t2_col3
t1_col4 t2_col4
t2_col1(FK)
Without a query plan, an actual query, or details about how your data are distributed it is not possible to make a concrete recommendation, but here are a few things to keep in mind.
Creating a foreign key does not automatically create an index on the foreign key column. It is simply a constraint.
Because joins between tables frequently involve foreign key columns, and because SQL Server will need to check the foreign key column regularly in order to enforce the constraint, it is usually a good idea to place an index on the foreign key column.
With what little you've described, your query has a criterion against the t1_col3 column - it will use that column to filter the values in table1; it might (it really depends on the query plan, and that's dependent on the distribution of data in the tables and other criteria and operations in the query) be a good idea to place an index on t1_col3.
For the third point, the usefulness of the index will depend a lot on the specific iterator/operator the query engine uses to implement a join between the two tables, and which table drives the join.
Any further information you can provide - the query, a query plan, number of rows - will help us provide a more specific answer.