Well, yes I do. I am receiving the following error:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-684-Answer' for key 'user_id' (SQL: insert into `votes` (`votable_id`, `votable_type`, `user_id`, `updated_at`, `created_at`) values (684, Answer, 1, 2016-03-17 12:16:53, 2016-03-17 12:16:53))
That would suggest I have a UNIQUE constraint on the user_id column? Looking at the DESCRIBE votes; I'm not sure whether this indicates that ot not. It shouldn't have though, one user should be able to vote many times:
mysql> describe votes;
+--------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | NO | MUL | NULL | |
| votable_id | int(11) | NO | | NULL | |
| votable_type | varchar(255) | NO | | NULL | |
| value | int(11) | NO | | NULL | |
| created_at | datetime | NO | | NULL | |
| updated_at | datetime | NO | | NULL | |
| deleted_at | datetime | YES | | NULL | |
+--------------+--------------+------+-----+---------+----------------+
mysql> show indexes from votes where column_name = 'user_id';
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| votes | 0 | user_id | 1 | user_id | A | 51 | NULL | NULL | | BTREE | | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
Does the above indicate that UNIQUE property is set? I'm looking at the migrations file and I can't see where the UNIQUE property was assigned. Perhaps someone put in manually.
This shows that there is an index user_id in your table.
you can use following code to see index that will list out all the indexes :
SHOW INDEX FROM votes;
if it doesnot solve your problem remove the unique index and recreate it again.
Non_unique = 0. It means it cannot contain duplicates. See SHOW INDEX documentation.
Related
I'm trying to drop some columns which I'm no longer using in my table. I've got a single column with a UNIQUE constraint. When I'm trying to drop the columns I'm getting a "Duplicate entry" found for this column.
When I search for rows with this code I'm only returned with a single result, but I figure that might be because it stops looking when it finds the first (as it thinks its unique).
I've tried deleting the row in question, but after trying to delete columns I'm returned with a new code that is "Duplicate entry".
Error when trying to delete columns:
ALTER TABLE attacktable DROP COLUMN fairfightparsed, DROP COLUMN defenderbattlestatssum, DROP COLUMN attackerbsstd, DROP COLUMN defenderdsstd, DROP COLUMN defenderlevel;
ERROR 1062 (23000): Duplicate entry 'e3cce98b6aa8085ed6a960d2afcd4dca' for key 'attacktable.attackcode'
Only one of the selected attackcode:
SELECT * FROM attacktable WHERE attackcode = "e3cce98b6aa8085ed6a960d2afcd4dca";
+----------------------------------+------------+ ...
| attackcode | attackerid | ...
+----------------------------------+------------+ ...
| e3cce98b6aa8085ed6a960d2afcd4dca | 2618403 | ...
+----------------------------------+------------+ ...
1 row in set (0,00 sec)
Description of uniqueness:
describe attacktable;
+------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------+--------------+------+-----+---------+-------+
| attackcode | varchar(255) | YES | UNI | NULL | |
| attackerid | int | YES | MUL | NULL | |
....
Indexes on the table:
SHOW INDEX FROM attacktable;
+-------------+------------+------------------------+--------------+------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+-------------+------------+------------------------+--------------+------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| attacktable | 0 | attackcode | 1 | attackcode | A | 1022111 | NULL | NULL | YES | BTREE | | | YES | NULL |
| attacktable | 1 | attackerid | 1 | attackerid | A | 2281 | NULL | NULL | YES | BTREE | | | YES | NULL |
| attacktable | 1 | resmodchain | 1 | resmodchain | A | 92 | NULL | NULL | YES | BTREE | | | YES | NULL |
| attacktable | 1 | resmodfair | 1 | resmodfair | A | 202 | NULL | NULL | YES | BTREE | | | YES | NULL |
| attacktable | 1 | resmodwar | 1 | resmodwar | A | 1 | NULL | NULL | YES | BTREE | | | YES | NULL |
| attacktable | 1 | attackerbattlestatssum | 1 | attackerbattlestatssum | A | 76782 | NULL | NULL | YES | BTREE | | | YES | NULL |
+-------------+------------+------------------------+--------------+------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
I'm now worried there are a lot of these duplicates in my table.. Help please :)
EDIT: SO I suspect it's the error-code that is wrong, not that I have duplicates. That would be easier I guess.
DELETE FROM attacktable WHERE attackcode = "e3cce98b6aa8085ed6a960d2afcd4dca";
Query OK, 1 row affected (0,02 sec)
SELECT * FROM attacktable WHERE attackcode = "e3cce98b6aa8085ed6a960d2afcd4dca";
Empty set (0,00 sec)
Solved it after finding this thread.
In my case it was caused due to continued writing to the table while I was trying to drop columns. I locked the table, dropped the columns and unlocked the tables again.
LOCK TABLE attacktable WRITE;
ALTER TABLE DROP COLUMN ...;
UNLOCK TABLES
I have an incredibly complex query being produced by an ORM, but here's the relevant portions for the sake of this question:
SELECT
...
FROM
`Broadcast` `t`
LEFT OUTER JOIN
`Site` `site`
ON (`t`.`site_id` = `site`.`id`)
LEFT OUTER JOIN
`Customer` `customer`
ON (`site`.`customer_id` = `customer`.`id`)
LEFT OUTER JOIN
`Domain` `domain`
ON (`customer`.`domain_id` = `domain`.`id`)
...
My fields are defined as follows:
>SHOW FIELDS FROM Broadcast;
+---------------------------+--------------------------------------+------+-----+------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------------------------------+------+-----+------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| site_id | int(10) unsigned | NO | MUL | NULL | |
...
>SHOW FIELDS FROM Site;
+---------------------------+---------------------+------+-----+------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+---------------------+------+-----+------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| customer_id | int(11) | NO | MUL | 0 | |
...
>SHOW FIELDS FROM Customer;
+---------------------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+------------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| domain_id | int(10) unsigned | NO | MUL | 1 | |
...
>SHOW FIELDS FROM Domain;
+---------------------------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
...
Why some of our IDs are int(11) and others are int(10) unsigned is just a matter of historical context. What's important is that the X_id foreign key always shares a type with the relevant id column. We never attempt to link an int(11) with an int(10) unsigned. Also the id field is always the primary key for the table.
We also have indexes on all of the foreign keys:
>SHOW INDEXES FROM Broadcast;
+-----------+------------+---------------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------+------------+---------------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Broadcast | 0 | PRIMARY | 1 | id | A | 139708 | NULL | NULL | | BTREE | | |
| Broadcast | 1 | site_id | 1 | site_id | A | 1060 | NULL | NULL | | BTREE | | |
...
>SHOW INDEXES FROM Site;
+-------+------------+----------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Site | 0 | PRIMARY | 1 | id | A | 1876 | NULL | NULL | | BTREE | | |
| Site | 1 | customer_id | 1 | customer_id | A | 250 | NULL | NULL | | BTREE | | |
...
>SHOW INDEXES FROM Customer;
+----------+------------+--------------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------+------------+--------------------------------------+--------------+---------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Customer | 0 | PRIMARY | 1 | id | A | 292 | NULL | NULL | | BTREE | | |
| Customer | 1 | domain_id | 1 | domain_id | A | 2 | NULL | NULL | | BTREE | | |
...
>SHOW INDEXES FROM Domain;
+--------+------------+-------------------------------------------+--------------+---------------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------+------------+-------------------------------------------+--------------+---------------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Domain | 0 | PRIMARY | 1 | id | A | 2 | NULL | NULL | | BTREE | | |
...
Each of these indexes consists of a single field, so the field is the first sequence in the index.
When I run EXPLAIN ... on my query, the output I get looks as follows:
Site and Customer are joined with the eq_ref type, but Domain is joined with ALL type. Why is MySQL not using my index?
I can force MySQL to use my index by adding USE INDEX FOR JOIN (domain_id) after the Customer table name, but this causes a new issue:
The problem just moves up from the Customer->Domain relation to the Site->Customer relation. I can shift the problem up one further using USE INDEX FOR JOIN (customer_id) after the Site table name, and as you might expect this just causes the Site table to join with the ALL type instead of eq_ref
I can't for the life of me figure out why MySQL is refusing to use my indexes
Per #ysth in the comments:
MySQL will not use an index if the table you are joining has very few rows, as the overhead of reading an index from disk exceeds the benefits
I have a schema with tables like this (simplified):
-------- --------------- ------------
| key | | permission | | resource |
|------| |-------------| |----------|
| id | -----< | id | >----- | id |
| name | | key_id | | name |
-------- | resource_id | ------------
| action |
---------------
The permission table definition script is something like this:
CREATE TABLE `permission` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`key_id` INT(11) NOT NULL,
`resource_id` INT(11) NOT NULL,
`action` VARCHAR(32) NOT NULL,
PRIMARY_KEY (`id`),
CONSTRAINT `fk_permission_key` FOREIGN KEY (`key_id`) REFERENCES `key` (`id`),
CONSTRAINT `fk_permission_resource` FOREIGN KEY (`resource_id`) REFERENCES `resource` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
This all works fine. Then, I decided I needed a unique constraint on the permission table so that only a single record can exist for an action/key/resource combination, so I do this:
ALTER TABLE `permission` ADD UNIQUE KEY `uq_permission` (`key_id`, `resource_id`, `action`);
This also works fine. We are in an environment where we use migrations to manage schema changes, so I want to make sure that there's a "roll back" script. But when I issue this command:
ALTER TABLE `permission` DROP INDEX `uq_permission`;
I get this error:
1553 - Cannot drop index 'uq_permission': needed in a foreign key
constraint
After some fuddling around, I found that if I dropped the foreign key fk_permission_key, I am then able to drop the unique constraint.
Why is my unique constraint getting tangled up with a completely separate foreign key?
When you add the fk_permission_key constraint, MySQL automatically creates an index (this behaviour differs from other database engines, where you need to create such indexes explicitly):
mysql> SHOW INDEX FROM `permission`;
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| permission | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_key | 1 | key_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_resource | 1 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
3 rows in set (0.00 sec)
When you create the uq_permission index, MySQL apparently drops the fk_permission_key index because it understands it can use your own index.
mysql> SHOW INDEX FROM `permission`;
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| permission | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 1 | key_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 2 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 3 | action | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_resource | 1 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
5 rows in set (0.01 sec)
However, if you now attempt to remove uq_permission MySQL complaints because the foreign key will no longer have a usable index (and this time it isn't smart enough to create the index automatically).
I don't know if automatic index creation is configurable but, in this case, the only solution I can think of is to provide the index yourself:
mysql> ALTER TABLE `permission` ADD INDEX `fk_permission_key` (`key_id`);
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> SHOW INDEX FROM `permission`;
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| permission | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 1 | key_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 2 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 0 | uq_permission | 3 | action | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_resource | 1 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_key | 1 | key_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
6 rows in set (0.01 sec)
mysql> ALTER TABLE `permission` DROP INDEX `uq_permission`;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> SHOW INDEX FROM `permission`;
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| permission | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_resource | 1 | resource_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
| permission | 1 | fk_permission_key | 1 | key_id | A | 0 | NULL | NULL | | BTREE | | | YES | NULL |
+------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
3 rows in set (0.00 sec)
Automatic index creation is documented:
MySQL requires indexes on foreign keys and referenced keys so that
foreign key checks can be fast and not require a table scan. 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. This index might be silently dropped later if you create
another index that can be used to enforce the foreign key
constraint. index_name, if given, is used as described previously.
I have a table called product categories. Structure is as follows:
+---------------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+------------+------+-----+---------+-------+
| sku | char(50) | NO | PRI | | |
| sorting_field | char(20) | NO | PRI | | |
| category | char(255) | NO | PRI | | |
| hide | tinyint(1) | NO | PRI | 0 | |
+---------------+------------+------+-----+---------+-------+
The following query runs an excessive amount of time on this table:
SELECT category FROM product_categories WHERE hide!=1 AND sorting_field="item_type" GROUP BY category;
When I run EXPLAIN, I get the following result:
+----+-------------+-----------------------------+-------+---------------+---------+---------+------+-------+-----------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------------------+-------+---------------+---------+---------+------+-------+-----------------------------------------------------------+
| 1 | SIMPLE | product_categories | index | NULL | PRIMARY | 976 | NULL | 43568 | Using where; Using index; Using temporary; Using filesort |
+----+-------------+-----------------------------+-------+---------------+---------+---------+------+-------+-----------------------------------------------------------+
I don't understand why this is happening at all! Why is the primary key not considered a possible key? This just doesn't make sense to me. By the way, here is the result of SHOW KEYS on this table:
+-----------------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-----------------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| product_categories | 0 | PRIMARY | 1 | sku | A | 8713 | NULL | NULL | | BTREE | |
| product_categories | 0 | PRIMARY | 2 | sorting_field | A | 43568 | NULL | NULL | | BTREE | |
| product_categories | 0 | PRIMARY | 3 | category | A | 43568 | NULL | NULL | | BTREE | |
| product_categories | 0 | PRIMARY | 4 | hide | A | 43568 | NULL | NULL | | BTREE | |
+-----------------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
Can anybody shed light on this dilemma for me?
If the table has a multiple-column index, any leftmost prefix of the index can be used by the optimizer to find rows.
Your index is (sku, sorting_field, category, hide), so you have index search capabilities on (sku), (sku, sorting_field), (sku, sorting_field, category) and (sku, sorting_field, category, hide).
In other words if you change your primary key to (sorting_field, hide, sku, category), primary key became a possible key of your query.
However i think you could find better solutions. For example:
create table product_categories (
sku char(50) not null,
sorting_field char(20) not null,
category char(255) not null,
hide tinyint(1) not null,
Primary key (sku, category),
key sorting_field (sorting_field, hide))
The possible_keys column of EXPLAIN is just a list of possibilities. The key column is what's actually going to be used in the query, and in your case, it's showing that it will use the PRIMARY.
Whats query can be used to get the details of Indexes of any table? I need this to find out primarykey/autoincremented value of any table..
Please help/Guide me...
You can use
show indexes from your_table;
For more informations : 12.4.5.23. SHOW INDEX Syntax
As a quick demo (on a not-quite-optimized table) :
mysql> show indexes from post;
+-------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| post | 0 | PRIMARY | 1 | id | A | 7 | NULL | NULL | | BTREE | |
| post | 1 | id_blog_idx | 1 | id_blog | A | 2 | NULL | NULL | | BTREE | |
| post | 1 | id_user_idx | 1 | id_user | A | 7 | NULL | NULL | | BTREE | |
| post | 1 | code_syntax_idx | 1 | code_syntax | A | 7 | NULL | NULL | | BTREE | |
| post | 1 | code_status_idx | 1 | code_status | A | 2 | NULL | NULL | | BTREE | |
| post | 1 | id_category_idx | 1 | id_category | A | 7 | NULL | NULL | | BTREE | |
+-------+------------+-----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
6 rows in set (0,00 sec)
Note, though, that this will display indexes -- and auto_increment doesn't have much to do with indexes.
If you want to see the auto_increment of your table, you can use desc :
desc your_table;
For more informations : 12.8.1. DESCRIBE Syntax
And, for example, with the same table :
mysql> desc post;
+--------------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| id_blog | int(10) unsigned | NO | MUL | NULL | |
| id_user | int(10) unsigned | NO | MUL | NULL | |
...
...
| nb_comments | smallint(6) | NO | | 0 | |
+--------------------+------------------+------+-----+---------+----------------+
17 rows in set (0,05 sec)
Also, an alternate way (which also shows you the current value of the AUTO_INCREMENT counter) is:
=> SHOW CREATE TABLE activations;
Yielding
CREATE TABLE `activations` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL,
`created_at` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=104974 DEFAULT CHARSET=utf8