I am new to databases. If I make a primary key with two columns, userId and dayOfWeek. How can I search this primary key?
(dayOfWeek is an int where 1 = Monday, 2 = Tuesday, etc.)
Would I do use:
SELECT *
WHERE userId = 1
AND dayOfWeek = 4
Would that scan the entire database or use information provided by the primary key? Is there another more appropriate query I could use?
A primary key index is internally much like any other index, except you're explicitly saying that THIS is the key which uniquely identifies a record. It's simply an index with a "must be unique" constraint imposed on it.
Whether the DB uses the composite primary key depends on how you specify the key fields in the query. Given your PK(userID, dayOfWeek), then
SELECT * FROM mytable WHERE (userID = 1);
SELECT * FROM mytable WHERE (userID = 1) AND (dayOfWeek = 4);
would both use the primary key index, because you've used the fields in the order they're specified within the key.
However,
SELECT * FROM mytable WHERE (dayOfWeek = 4)
will not, because userID was not specified, and userID comes before dayOfWeek in the key definition.
No query will scan the entire database, unless you specified all the tables within that database. At worst, you could expect a table scan (which is what I think you really meant) if you were searching by columns that were not the primary key or indexed.
Your example is a composite primary key because it uses more than one column as the key. MySQL now automatically indexes the primary key (since v5?), so searching by all primary key columns is less likely to result in a table scan but rather an index seek/scan. It depends on if any other criteria is used. Searching by part of the primary key (IE: user_id only) might make use of the index - assuming it's a covering index, if the user_id column is the first from the left then the index could be used. Otherwise not.
Related
I have a table A that has n number of columns: amongst them id (primary key), name and org_id. Names must be unique within org_id, so I am slapping unique key constraint on that pair.
Now, in the application code, I have checks, where I verify if name for my entity is unique across organization.
The query looks like:
SELECT * FROM A WHERE name=? and org_id=?
I have org_id as a foreign key to Organizations table.
In order to speed up queries as I mentioned above, should I introduce an index against the name column? Or, maybe, there is no need, and the Unique Key index (org_id-name) will kick in and make my queries fast?
The UNIQUE constraint is already backed by an index. I assume it takes the form:
constraint uq_1 unique (org_id, name)
Your query should be fast already when using "equality searches", like the one you show, using the predicate:
WHERE name = ? and org_id = ?
I have a table with several fields that I'm trying to index:
user_id = Int that divides the data between user accounts.
item_number = Non-unique Int that a user sets when creating new items.
I have two indexes:
idx_user_id: Fields = user_id, Type = BTREE, Unique = NO
idx_user_id_item_number: Fields = user_id AND item_number, Type =
BTREE, Unique = YES
I'm wondering if idx_user_id is unnecessary because we also start our idx_user_id_item_number with user_id and queries will use that and get the same result. My only concern is that because the idx_user_id_item_number index is unique, it might be necessary to keep both.
Your index on (user_id) is redundant with your index on (user_id, item_number). You don't need the first index. You should drop it, because it takes storage space and slows down update and insert operations.
For the purpose of indexing MySQL uses the leading column or columns in a multicolumn index as if they were a standalone index.
Notice this though, if your index on (user_id) were a unique index and the other one was not, you'd need both indexes. Why? in that case you'd be using the first index for the purpose of enforcing the uniqueness constraint.
Having a PRIMARY KEY is important.
A PK is UNIQUE.
So, get rid of both indexes and have only
PRIMARY KEY(user_id, item_number)
I created this table:
CREATE TABLE incident_originator (
id_incident INT (11) UNSIGNED NOT NULL,
id_user INT (11) NOT NULL,
PRIMARY KEY (
id_incident,
id_user
),
CONSTRAINT fk_incident_incident_originator FOREIGN KEY (id_incident) REFERENCES incident_table (id_incident) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_user_incident_originator FOREIGN KEY (id_user) REFERENCES users (id_user) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE = INNODB DEFAULT CHARSET = latin1;
Yet, the fk_user_incident_originator, is indexed, and the fk_incident_incident_originator is not. Why is that? Isn't InnoBD supposed to automatically index all foreign keys? The lack of an index in the id_incident would make joins slower, wouldn't it? The more I read, the less I understand...
Plus, when I add values to the table, they are ordered by the second column and it gets weird to read as a human being.
EDIT: When I do a SHOW INDEX FROM incident_originator; it returns this:
Non_unique Key_name Seq_in_index Column_name
0 PRIMARY 1 id_incident
0 PRIMARY 2 id_user
1 fk_user_incident_originator 1 id_user
fk_incident_incident_originator is not
Sure it is.
PRIMARY KEY (id_incident,id_user),
In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist.
https://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
id_incident is the first (meaning left-most) column of the primary key... and the primary key is a perfectly good index for looking up values when enforcing the constraint. To add a second index would be redundant.
The same is true for joins (though joins are not the actual reason foreign keys are always indexed) -- any index that includes all of the joined columns anchored to the left side of the index is quite valid for a join.
they are ordered by the second column and it gets weird to read as a human being.
Tell any humans you know that the database doesn't order its output for the benefit of humans unless the humans use ORDER BY. Result sets without ORDER BY are unordered by definition. The fact that rows are often returned in primary key order is by coincidence, not by design or necessity. This behavior may shift when the table gets larger as the optimizer changes strategies when reading the table... but since the index on id_user is in fact a covering index (it contains all the columns in the table, because all indexes also contain a copy of the primary key... or, more precisely, it contains all the columns needed to satisfy this particular query -- those are sometimes two different things, and this is one of the best reasons not to use SELECT * in your actual code) so the optimizer happens to be selecting it as its source. It reads the rows in index order from whatever index it selects, and that order becomes the entirely coincidental ordering of the result.
When should I use KEY, PRIMARY KEY, UNIQUE KEY and INDEX?
KEY and INDEX are synonyms in MySQL. They mean the same thing. In databases you would use indexes to improve the speed of data retrieval. An index is typically created on columns used in JOIN, WHERE, and ORDER BY clauses.
Imagine you have a table called users and you want to search for all the users which have the last name 'Smith'. Without an index, the database would have to go through all the records of the table: this is slow, because the more records you have in your database, the more work it has to do to find the result. On the other hand, an index will help the database skip quickly to the relevant pages where the 'Smith' records are held. This is very similar to how we, humans, go through a phone book directory to find someone by the last name: We don't start searching through the directory from cover to cover, as long we inserted the information in some order that we can use to skip quickly to the 'S' pages.
Primary keys and unique keys are similar. A primary key is a column, or a combination of columns, that can uniquely identify a row. It is a special case of unique key. A table can have at most one primary key, but more than one unique key. When you specify a unique key on a column, no two distinct rows in a table can have the same value.
Also note that columns defined as primary keys or unique keys are automatically indexed in MySQL.
KEY and INDEX are synonyms.
You should add an index when performance measurements and EXPLAIN shows you that the query is inefficient because of a missing index. Adding an index can improve the performance of queries (but it can slow down modifications to the table).
You should use UNIQUE when you want to contrain the values in that column (or columns) to be unique, so that attempts to insert duplicate values result in an error.
A PRIMARY KEY is both a unique constraint and it also implies that the column is NOT NULL. It is used to give an identity to each row. This can be useful for joining with another table via a foreign key constraint. While it is not required for a table to have a PRIMARY KEY it is usually a good idea.
Primary key does not allow NULL values, but unique key allows NULL values.
We can declare only one primary key in a table, but a table can have multiple unique keys (column assign).
PRIMARY KEY AND UNIQUE KEY are similar except it has different functions. Primary key makes the table row unique (i.e, there cannot be 2 row with the exact same key). You can only have 1 primary key in a database table.
Unique key makes the table column in a table row unique (i.e., no 2 table row may have the same exact value). You can have more than 1 unique key table column (unlike primary key which means only 1 table column in the table is unique).
INDEX also creates uniqueness. MySQL (example) will create a indexing table for the column that is indexed. This way, it's easier to retrieve the table row value when the query is queried on that indexed table column. The disadvantage is that if you do many updating/deleting/create, MySQL has to manage the indexing tables (and that can be a performance bottleneck).
Hope this helps.
Unique Keys: The columns in which no two rows are similar
Primary Key: Collection of minimum number of columns which can uniquely identify every row in a table (i.e. no two rows are similar in all the columns constituting primary key). There can be more than one primary key in a table. If there exists a unique-key then it is primary key (not "the" primary key) in the table. If there does not exist a unique key then more than one column values will be required to identify a row like (first_name, last_name, father_name, mother_name) can in some tables constitute primary key.
Index: used to optimize the queries. If you are going to search or sort the results on basis of some column many times (eg. mostly people are going to search the students by name and not by their roll no.) then it can be optimized if the column values are all "indexed" for example with a binary tree algorithm.
The primary key is used to work with different tables. This is the foundation of relational databases. If you have a book database it's better to create 2 tables - 1) books and 2) authors with INT primary key "id". Then you use id in books instead of authors name.
The unique key is used if you don't want to have repeated entries. For example you may have title in your book table and want to be sure there is only one entry for each title.
Primary key - we can put only one primary key on a table into a table and we can not left that column blank when we are entering the values into the table.
Unique Key - we can put more than one unique key on a table and we may left that column blank when we are entering the values into the table.
column take unique values (not same) when we applied primary & unique key.
Unique Key :
More than one value can be null.
No two tuples can have same values in unique key.
One or more unique keys can be combined to form a primary key, but not vice versa.
Primary Key
Can contain more than one unique keys.
Uniquely represents a tuple.
When should I use KEY, PRIMARY KEY, UNIQUE KEY and INDEX?
KEY and INDEX are synonyms in MySQL. They mean the same thing. In databases you would use indexes to improve the speed of data retrieval. An index is typically created on columns used in JOIN, WHERE, and ORDER BY clauses.
Imagine you have a table called users and you want to search for all the users which have the last name 'Smith'. Without an index, the database would have to go through all the records of the table: this is slow, because the more records you have in your database, the more work it has to do to find the result. On the other hand, an index will help the database skip quickly to the relevant pages where the 'Smith' records are held. This is very similar to how we, humans, go through a phone book directory to find someone by the last name: We don't start searching through the directory from cover to cover, as long we inserted the information in some order that we can use to skip quickly to the 'S' pages.
Primary keys and unique keys are similar. A primary key is a column, or a combination of columns, that can uniquely identify a row. It is a special case of unique key. A table can have at most one primary key, but more than one unique key. When you specify a unique key on a column, no two distinct rows in a table can have the same value.
Also note that columns defined as primary keys or unique keys are automatically indexed in MySQL.
KEY and INDEX are synonyms.
You should add an index when performance measurements and EXPLAIN shows you that the query is inefficient because of a missing index. Adding an index can improve the performance of queries (but it can slow down modifications to the table).
You should use UNIQUE when you want to contrain the values in that column (or columns) to be unique, so that attempts to insert duplicate values result in an error.
A PRIMARY KEY is both a unique constraint and it also implies that the column is NOT NULL. It is used to give an identity to each row. This can be useful for joining with another table via a foreign key constraint. While it is not required for a table to have a PRIMARY KEY it is usually a good idea.
Primary key does not allow NULL values, but unique key allows NULL values.
We can declare only one primary key in a table, but a table can have multiple unique keys (column assign).
PRIMARY KEY AND UNIQUE KEY are similar except it has different functions. Primary key makes the table row unique (i.e, there cannot be 2 row with the exact same key). You can only have 1 primary key in a database table.
Unique key makes the table column in a table row unique (i.e., no 2 table row may have the same exact value). You can have more than 1 unique key table column (unlike primary key which means only 1 table column in the table is unique).
INDEX also creates uniqueness. MySQL (example) will create a indexing table for the column that is indexed. This way, it's easier to retrieve the table row value when the query is queried on that indexed table column. The disadvantage is that if you do many updating/deleting/create, MySQL has to manage the indexing tables (and that can be a performance bottleneck).
Hope this helps.
Unique Keys: The columns in which no two rows are similar
Primary Key: Collection of minimum number of columns which can uniquely identify every row in a table (i.e. no two rows are similar in all the columns constituting primary key). There can be more than one primary key in a table. If there exists a unique-key then it is primary key (not "the" primary key) in the table. If there does not exist a unique key then more than one column values will be required to identify a row like (first_name, last_name, father_name, mother_name) can in some tables constitute primary key.
Index: used to optimize the queries. If you are going to search or sort the results on basis of some column many times (eg. mostly people are going to search the students by name and not by their roll no.) then it can be optimized if the column values are all "indexed" for example with a binary tree algorithm.
The primary key is used to work with different tables. This is the foundation of relational databases. If you have a book database it's better to create 2 tables - 1) books and 2) authors with INT primary key "id". Then you use id in books instead of authors name.
The unique key is used if you don't want to have repeated entries. For example you may have title in your book table and want to be sure there is only one entry for each title.
Primary key - we can put only one primary key on a table into a table and we can not left that column blank when we are entering the values into the table.
Unique Key - we can put more than one unique key on a table and we may left that column blank when we are entering the values into the table.
column take unique values (not same) when we applied primary & unique key.
Unique Key :
More than one value can be null.
No two tuples can have same values in unique key.
One or more unique keys can be combined to form a primary key, but not vice versa.
Primary Key
Can contain more than one unique keys.
Uniquely represents a tuple.