I am using PhpMyAdmin to add indexes on the tables but whenever i try to add one it prints errors...
I have a table called updates_categories and i have a column named created_date... so i tried to add an index there and i get the following error:
#1062 - Duplicate entry '2012-02-27 22:15:16' for key 'date_index'
i suppose that many entries have entered the same date(this can happen) but what does that mean?That i cant have an index on columns with same data?
Do not add an index for only one field becouse most of the time it has no performance benefit on select but they got disadvantages on inserts. What is your table structure and what kind of queries are you using against it?
Yes, you can - but don't use it as "UNIQUE" keys, just "simple" index.
what kind of index did you try to create?
unique and primary key require that no key exists more than once
Related
Hello i have a simple table with id|id_account|type|user all work but after i indexed "id_account" with UNIQUE my script not work with EDIT (but work with INSERT)
id_account is a sha256 like this format: 8a9a9a9b63617d857...
What is the good index for that ?
I need to drop all and reindex yes ?
Thanks (sorry for my little english)
UNIQUE is not only index but also constraint. Not sure what you calls "EDIT" but believe your issue deals with that constraint, and you making duplicated values for that constraint. (ref https://dev.mysql.com/doc/refman/5.7/en/constraint-primary-key.html)
possible issue - you making table update (EDIT) with wrong WHERE clause, which causes modification of more than one record in your table with same id_account value - and this is not allowed since you using UNIQUE constraint.
I have a problem with creating index described in answer for this question: sql unique constraint on a 2 columns combination
I am using MySql, and I received syntax error, my version of this query is as follows:
CREATE UNIQUE INDEX ON friends (LEAST(userID, friendID), GREATEST(userID, friendID));
LEAST and GREATEST functions are available in MySql, but maybe the syntax should be different?
I tried to make an ALTER TABLE version, but it does not worked as well.
In MySQL, you can't use functions as the values for indexes.
The documentation does not explicitly state this, however, it is a basic characteristic of an index to only support "fixed" data:
Indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows.
Generally, this "fixed" data is an individual column/field; with string-fields (such as varchar or text) you can have a prefix-index and not the entire column. Check out CREATE INDEX for more info on that.
The unique index that you're trying to create in you example will have a single record ever; that's not really a beneficial index since it doesn't help for searching the entire table. However, if you index your table on userID, friendID, using the LEAST() and GREATEST() functions in a SELECT statement will be optimized thanks to the index itself, so it may be what you're after in this case.
As far as indexing goes, is it proper to index all fields that will be searched (within a WHERE) clause to speed up SELECTS? For example my database contains a profiles table which stores user information such as name, intrestCode,zip, description, and email. The profile record is identified by a PRIMARY id column which uniquely corresponds with the userid. I made zip and intrestCode an index since profiles will be searched by zip and possibly intrestCode (SELECT `blah`,`blah`... FROM profile WHERE zip=?, SELECT `blah`,`blah`... FROM profile WHERE zip=? && intrestCode=?). Am I doing it right?
Sounds basically correct. You should be aware that you can't use two different indices on the same table in the same query, so if you ran
CREATE INDEX `zip` ON `profile` (`zip`);
CREATE INDEX `intrestCode` ON `profile` (`intrestCode`);
then the query
SELECT `blah`,`blah`... FROM profile WHERE zip=? && intrestCode=?
can only look up one table from the index. The secret here is that you can create a single index on two tables, like so:
CREATE INDEX `zip+intrestCode` ON `profile` (`zip`, `intrestCode`);
MySQL can use this for queries that use either zip alone in the WHERE clause, or use both zip and intrestCode, but not for queries that use only intrestCode in the WHERE clause.
(This is because each index covers the whole table. If MySQL were to try and look up zip and intrestCode from different tables, then it would be retrieving lots of irrelevant rows from the second index. Therefore, it only looks at one index. If you want it to use the index on both columns, you need to have one index that includes both columns.)
Indexing relation datbases is a bit of an art. The best approach is to look at all the different queries you will be making and putting indices on the columns involved. Use EXPLAIN to see what indices a query is going to use.
However, remember that MySQL can only use one index from a table at a time. This is why you can put an index on multiple columns at once. And MySQL can use a multi-column index if it only needs the columns in the start of the index. In your example, I would put a multi-column index zip and intrestCode together because that will help both queries. That way you don't need a separate index on just zip.
I believe basically yes. You should monitor your database to encounter further problems and optimize your queries and tables based on the results too.
Generally you want to add indexes to columns that you will join on or have in your where clause. Remember that an index on two columns is different than one index on each of the two columns. Also if you have an index on multiple columns the order matters.
Say you have two columns A and B and have an two column index in the order A then B. There are three cases:
Where clause against column A: index is used
Where clause against column B: index is NOT used
Where clause against columns A and B: index is used
Like staticsan says, indexing is an art and there are no rules that apply 100% of the time. Use the explain plan to see how your query is performing and make tweaks accordingly.
Ok so I've a SQL query here:
SELECT a.id,... FROM article AS a WHERE a.type=1 AND a.id=3765 ORDER BY a.datetime DESC LIMIT 1
I wanted to get exact article by country and id and created for that index with two columns type and id. Id is also primary key.
I used the EXPLAIN keyword to see which index is used and instead of the multiple column index it used primary key index, but I did set the where stuff exactly in order as the index is created.
Does MySQL use the primary key index instead of the multiple column index because the primary one is faster? Or should I force MySql to use the multiple column index?
P.S. Just noticed it was stupid to use order when there is 1 result row. Haha. It increased the search time for 0.0001 seconds. :P
I don'e KNOW, but I would THINK that the primary key index would be the fastest available. And if it is, there's not much use using any other index. You're either going to have a article with an id of 3765 or you're not. Scanning that single row to determine if the type matches is trivial.
If you're only returning one row, there's no point to your ORDER BY clause. And the only point to the a.type=1 is to reject an article with the right id if the type is not correct.
MySQL allows for up to 32 indexes for each table, and each index can incorporate up to 16 columns. A multiple-column / composite index is considered a sorted array containing values that are created by concatenating the values of the indexed columns. MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you do not specify values for the other columns.
If you look very carefully in how MySQL uses indexes, you will find that indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows.
In MySQL, a primary key column is automatically indexed for efficiency, as they use the in-built AUTO_INCREMENT feature of MySQL. On the other hand, one should not go overboard with indexing. While it does improve the speed of reading from databases, it slows down the process of altering data in a database (because the changes need to be recorded in the index). Indexes are best used on columns:-
that are frequently used in the WHERE part of a query
that are frequently used in an ORDER BY part of a query
that have many different values (columns with numerous repeating values ought not to be indexed).
So I try to use the primary key if my queries can suffice its use. When & only when it is required for more such indexing & fastness of fetching records, do I use the composite indexes.
Hope it helps.
The primary key is unique, so there's no need for MySQL to check any other index. a.id=3765 guarantees that there will be no more than one row returned. If a.type=1 is false for that row, then nothing will be returned.
I'm trying to insert items into my postgres table via PHP
But get the following error message ERROR: duplicate key violates unique constraint "search6_idx1"
search6_idx1 is the index table for search6. I tried the following select setval('search6',45) and somehow that only works for sequences.
When you define an index you can optionally make it UNIQUE. Such indexes serve a double purpose:
Speed up queries
Prevent duplicates
In your case, it seems that the problem is one of these:
You are inserting values that already exist
Your index is UNIQUE by mistake
The respective solutions would be:
Don't insert dupes
Make a non-unique index