I have a table which in my opinion will benefit from partitioning:
CREATE TABLE [dbo].[my_table](
[id] [int] IDENTITY(1,1) NOT NULL,
[external_id] [int] NOT NULL,
[amount] [money] NOT NULL,
PRIMARY KEY CLUSTERED ([id] ASC));
There are just few different external_id and thousands of records for each of them.
SSMS Create Partition Wizard generates a script that I don't completely understand. After creating partition function and partition schema,
--it drops Primary Key,
--then creates Primary Key again on id, this time as non-clustered,
--then creates clustered index on external_id on newly created partition schema,
--and finally it drops the clustered index created on previous step.
Everything except last step seems clear, but I cannot get why it has to drop the clustered index. Should I remove the last step from the batch?
Any help will be greatly appreciated.
It makes sense.
The partition key is going to be the external id, so the clustered index must include that.
It preserves the primary key in a non-clustered index - since it's on ID not external_id
It created the clustered index on external_id to physically move the data into the partition scheme.
It drops the clustered index since it only used it to move the data - it was not a previously specified index.
There are a number of alternatives, assuming you always know the external_id, then you could choose to create the clustered index as (id,external_id) - the partition schema / function field used for the table must be within the clustered index on the partition schema.
Performance wise, this is not going to be a huge boost, the use of it is more that you can drop an entire external_id trivially, instead of a large delete transaction.
Related
This is driving me nuts, can someone tell me what is the purpose of using clustered keywords after primary key in MySQL? In which condition I have to use it? Does it depend on the primary key data type?
Example:
create table Orders
(
OrderID int not null auto_increment,
CustID smallint not null, -- FK Customers table
EmpID smallint not null, -- FK Employees table
constraint pk_Orders primary key clustered (OrderID asc)
);
Tnx in advance.
SQL will create an index on default on primary key column.
Index is used similairly as you use index in a book - you want to look-up something in a book, you look at an index to see where it occurs in a book.
Obviously, you could find that without an index, but it would be extremely slow.
So, index is something, that will speed up queries.
A clustered index (SQL Server, MySQL/InnoDB) is a table stored in an index B-Tree structure. There is no second data structure (heap-table) for the table.
Non-clustered index has no effect on how data is stored, it just has informations where to find particular row based on indexed column.
More can be found here: Clustered Index / Non-Clustered Index
I realized, that when I am creating foreign keys in table, indexes are adding automatically.
In my table:
CREATE TABLE `SupplierOrderGoods` (
`shopOrder_id` INT(11) NOT NULL,
`supplierGood_id` INT(11) NOT NULL,
`count` INT(11) NOT NULL,
PRIMARY KEY (`shopOrder_id`, `supplierGood_id`),
CONSTRAINT `FK_SupplierOrderGoods_ShopOrders` FOREIGN KEY (`shopOrder_id`) REFERENCES `shoporders` (`id`),
CONSTRAINT `FK_SupplierOrderGoods_SupplierGoods` FOREIGN KEY (`supplierGood_id`) REFERENCES `suppliergoods` (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB;
Index
INDEX `FK_SupplierOrderGoods_SupplierGoods` (`supplierGood_id`)
have been created automatically.
It is okay, that index have been created as I found in another post. I was looking what indexes are used for and found, that they are used for optimizing search in tables.
Now, I know, that I have to use indexes to optimize work with database.
Also, I found, that indexes can be complex (not on one field, but on some fields). In that case, I want to ask should I use complex index:
INDEX `FK_ShopOrders_SupplierGoods` (`shopOrder_id`, `supplierGood_id`),
or two simple indexes?:
INDEX `FK_SupplierOrderGoods_SupplierGoods` (`supplierGood_id`),
INDEX `FK_SupplierOrderGoods_ShopOrders` (`shopOrder_id`),
I'm still earning about indexes myself but I believe it's going to depend on what kind of data you will be querying the DB for.
For example, if you have a report for a certain record that will be ran a lot you'll want an index on it. If the report pulls just one column then make a one column index, if it's comprised of two, like a first name and a last name record, you'll probably want one for both.
You do not want to put an index on everything though as that can have performance issues as both the record and the index need to be updated. As such, tables that have a high amount of inserts or updating done on them you'll want to think about whether an index hurts or helps.
Lot of information to cover with indexes.
When using the command:
ALTER TABLE my_table DROP PRIMARY KEY;
The state (when SHOW PROCESSLIST) appears as:
copy to tmp table
Why would it need to use a tmp table to "drop" a primary key constraint?
Consider the case of a composite primary key. In this case, the DB engine has to create a new clustered index from a synthetic key, which will require moving rows around. (Keep in mind that rows are physically ordered on disk by the primary key.) Given the rarity of this situation, it's not really worth handling the special case where your primary key is already an integer.
I have a massive (3,000,000,000 rows) fact table in a datawarehouse star schema. The table is partitioned on the date key.
I would like to add an index on one of the foreign keys. This is to allow me to identify and remove childless rows in a large dimension table.
If I just issue a CREATE INDEX statement then it would take forever.
Do any SQL gurus have any fancy techniques for this problem?
(SQL 2008)
--Simplified example...
CREATE TABLE FactRisk
(
DateId int not null,
TradeId int not null,
Amount decimal not null
)
--I want to create this index, but the straightforward way will take forever...
CREATE NONCLUSTERED INDEX IX_FactRisk_TradeId on FactRisk (TradeId)
I have a plan...
Switch out all the daily partitions to tables
Index the now empty fact table
Index the individual partition
Switch all the partitions back in
Initial investigation implies that this will work. I will report back...
When using DataContext.CreateDatabase() to create a database, I wish to stop Linq To Sql creating a clustered index on the primary key of a table.
This is because I wish to create a normal index for the primary key, as I need the clustered index to spread up range queries on a date field.
It seems that you can't control what DataContext.CreateDatabase Does.