Resetting mysql integer value - mysql

I have MySQL table name Order_Ticket_Number as following:
CREATE TABLE order_ticket_number (
id_store_ticket int(10) NOT NULL,
id_order_ticket int(3) ZEROFILL AUTO_INCREMENT NOT NULL,
id_date_order timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
id_order int(10) unsigned NOT NULL default 0,
PRIMARY KEY (id_store_ticket,id_order_ticket,id_date_order)
)
ENGINE=myisam DEFAULT CHARSET=utf8;
I want to restart the value of id_order_ticket each time I open a store from the Python application I am developing. id_order_ticket is starting with 001, 002 ... and I want every day to start with 001 when I am making SOD(start-of-day). There will be not conflict to have two time ex.id_order_ticket = 001 because id_date_order is also PK and Engine=myisam.
Thank you

If I understand correctly, you need to change the order of columns in the primary key and use a DATE column, not timestamp:
PRIMARY KEY (id_store_ticket, id_date, id_order_ticket)
Example, tested in SQL-Fiddle:
CREATE TABLE order_ticket_number
( id_store_ticket int(10) NOT NULL,
id_date DATE NOT NULL,
id_order_ticket int(3) ZEROFILL AUTO_INCREMENT NOT NULL,
id_date_order timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
id_order int(10) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (id_store_ticket, id_date, id_order_ticket)
)
ENGINE = MyISAM ;
Dates cannot have a DEFAULT CURRENT_TIMESTAMP property, so yuo have to ensure that the date and timestamp columns have consistent values.

Mysql documentation states that it is impossible:
To change the value of the AUTO_INCREMENT counter to be used for new
rows, do this:
ALTER TABLE t2 AUTO_INCREMENT = value; You cannot reset the counter to
a value less than or equal to any that have already been used.
reference

Related

MySql table have two or more columns have default date vaule CURRENT_TIMESTAMP,any Solutions?

if i have a table with two columns create_time and update_time,the data type is timestamp,then have default value CURRENT_TIMESTAMP,the sql code of created table is:
CREATE TABLE `t_activity` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`STARTDATE` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`ENDDATE` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`)
);
but it prompt error:1293,there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or UPDATE clause.
I am not sure what you're trying to accomplish having both the STARTDATE and ENDDATE populated with the CURRENT_TIMESTAMP. However to fix your code try changing your data types to DATETIME like this:
**CREATE TABLE `t_activity` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`STARTDATE` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`ENDDATE` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`)
);**
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-5.html
This limitation in Mysql:
Previously, at most one TIMESTAMP column per table could be
automatically initialized or updated to the current date and time.
This restriction has been lifted. Any TIMESTAMP column definition can
have any combination of DEFAULT CURRENT_TIMESTAMP and ON UPDATE
CURRENT_TIMESTAMP clauses. In addition, these clauses now can be used
with DATETIME column definitions. For more information, see Automatic
Initialization and Updating for TIMESTAMP and DATETIME.
Check This for more detail
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-5.html

MySQL adding (num) to smallint column

When I create a table in MySQL specifying smallint as a column, but then use show create table or even mysqldump, MySQL has added (5) after the smallint definition, as below.
I'm guessing it doesn't really matter as far as the data is concerned, but can anyone explain why and if/how I can stop it doing this?
As an aside, I am attempting to change an existing database table to exactly match that of a new sql script. I could always alter the new sql script, but I'd prefer to alter the existing table if possible (think software install versus software upgrade).
DROP TABLE IF EXISTS `test`;
CREATE TABLE `test` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`status` varchar(100) NOT NULL DEFAULT '',
`port` smallint unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SHOW CREATE TABLE test;
CREATE TABLE `test` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`status` varchar(100) NOT NULL DEFAULT '',
`port` smallint(5) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
No, you can't stop the SHOW CREATE TABLE from including the display width attribute for integer types.
If a value for the display width is not included in the column declaration of an integer type, MySQL supplies a default value for it. A value of 5 is the default value for SMALLINT UNSIGNED.
The display width doesn't have any affect on the values that can be stored or retrieved. Client applications can make use of the value for formatting a resultset.
Reference: http://dev.mysql.com/doc/refman/5.6/en/numeric-type-attributes.html
tMySQL is simply setting the (displayed) length of the column to match he data type (max value 65535, five digits). To change this, you can write:
port smallint (3) unsigned NOT NULL DEFAULT '0',
if you like.
Try this start adding values in your table.
<mysql> CREATE TABLE test(
-> ID SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
-> Name VARCHAR(100) NOT NULL
-> );>

MySQL - convert MyISAM into InnoDB getting error 1075

I am trying to convert a table from MyISAM into InnoDB, this is the definition and I am getting error #1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key
The table has an AutoIncrement value and the field is indexed and it works with MyISAM. I am new to InnoDB so it might be a dumb question
CREATE TABLE `cart_item` (
`cart_id` int(10) unsigned NOT NULL DEFAULT '0',
`id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
`design_number` int(10) unsigned NOT NULL,
`logo_position_id` smallint(5) unsigned NOT NULL,
`subst_style_id` varchar(10) DEFAULT NULL,
`style_id` varchar(10) NOT NULL DEFAULT '',
`subst_color_id` smallint(5) unsigned DEFAULT NULL,
`color_id` smallint(5) unsigned NOT NULL,
`size_id` smallint(5) unsigned NOT NULL,
`qty` mediumint(8) unsigned NOT NULL,
`active` enum('y','n') NOT NULL DEFAULT 'y',
`date_last_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`last_modified_by_id` mediumint(5) unsigned NOT NULL,
`date_last_locked` datetime DEFAULT NULL,
`last_locked_by_id` smallint(5) unsigned NOT NULL,
`date_added` datetime NOT NULL,
`subsite_logo_group_id` int(11) NOT NULL,
`bundle` varchar(32) NOT NULL,
`color_stop_1` varchar(4) DEFAULT NULL,
PRIMARY KEY (`cart_id`,`id`),
KEY `color_id` (`color_id`),
KEY `style_id` (`style_id`),
KEY `size_id` (`size_id`),
KEY `design_number` (`design_number`),
KEY `subsite_logo_group_id` (`subsite_logo_group_id`),
KEY `date_added` (`date_added`),
KEY `bundle` (`bundle`)
) ENGINE=InnoDB
What you were doing on the MyISAM table, cannot be done with InnoDB. See my answer on a (similar) problem: creating primary key based on date
MySQL docs, in the Using AUTO_INCREMENT section, explain it:
For MyISAM tables you can specify AUTO_INCREMENT on a secondary column in a multiple-column index. In this case, the generated value for the AUTO_INCREMENT column is calculated as MAX(auto_increment_column) + 1 WHERE prefix=given-prefix. This is useful when you want to put data into ordered groups.
You may get similar behaviour in InnoDB but not with AUTO_INCREMENT. You'll have to use either some fancy trigger or a stored procedure for your Inserts that will take care of the (per cart_id) auto-increment.
You have a composite PRIMARY KEY defined on (cart_id, id), but the AUTO_INCREMENT requires an index on id alone. You can add a KEY for it (not a primary key, but just a plain index):
KEY `idx_id` (`id`)
I question the use of the composite PK on (cart_id, id) though, since id is alone a unique value by definition. Perhaps you should make id the PK, and create a separate index across the combination.
PRIMARY KEY (`id`),
KEY (`cart_id`, `id`)
It doesn't even need to be specified as UNIQUE because the AUTO_INCREMENT can't be repeated anyway. There is no way to violate uniqueness on the combination (cart_id, id).
AUTO_INCREMENT columns should be define as key, as what the error implies.
`id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
and set UNIQUE on the two column instead of primary key
UNIQUE (`cart_id`,`id`),
SQLFiddle Demo

What is the reason for Mysql error code 1293

Here is the message of mysql error 1293:
SQL Error (1293): Incorrect table definition; there can be only one
TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
what is the reason for mysql only allows one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause per table.
Only one TIMESTAMP field can default to "now"
I should say first of all, if you are trying to define more than one MySQL TIMESTAMP fields using CURRENT_TIMESTAMP or "default now", unfortunately that is bad, you can't do it in MySQL
I just got this MySQL TIMESTAMP error when trying to create a table like this:
create table users (
id int unsigned auto_increment not null primary key,
username varchar(50) not null unique,
password varchar(40) not null,
email_address varchar(128) not null unique,
email_sent timestamp not null,
last_login timestamp not null default now()
) ENGINE = InnoDB;
When I first solved this problem I thought MySQL required the "CURRENT_TIMESTAMP (default now)" field to be declared before any other TIMESTAMP fields, so I solved my problem like this:
create table users (
id int unsigned auto_increment not null primary key,
username varchar(50) not null unique,
password varchar(40) not null,
email_address varchar(128) not null unique,
last_login timestamp not null default now(),
email_sent timestamp not null
) ENGINE = InnoDB;

proper index (or removal) to optimize a large data set table

We have a 'visitor' tracking schema going on - that when pushed, seems to be causing some strain on the DB server.
VISITORS table identifies unique users by a HASH (current records 310,000). A search is performed on the hash, and if not found, it is added. The ID is needed for the following two tables
CREATE TABLE visitors (
id int(10) UNSIGNED NOT NULL auto_increment,
ip varchar(25) NOT NULL,
hash varchar(64) NOT NULL,
first_visit varchar(32) NOT NULL,
created_at datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE visitors ADD UNIQUE INDEX (hash);
ALTER TABLE visitors ADD INDEX (created_at);
VISITOR_VISITS table identifies when a user visited only when we can identify some referral sources (current count 142,000). A search is performed looking for the visitor_id, type and visit_date. If there is nothing found - it is added. The ID is used in the following table.
CREATE TABLE visitor_visits (
id int(10) UNSIGNED NOT NULL auto_increment,
visitor_id int(10) UNSIGNED NOT NULL,
source varchar(64) NULL DEFAULT NULL DEFAULT NULL,
medium varchar(64) NULL DEFAULT NULL,
campaign varchar(256) NULL DEFAULT NULL,
page varchar(32) NULL DEFAULT NULL,
landing varchar(32) NULL DEFAULT NULL,
type enum('fundraiser_view') NULL DEFAULT NULL,
visit_date date NOT NULL default '0000-00-00',
created_at datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE visitor_visits ADD UNIQUE INDEX (visitor_id,type,visit_date);
ALTER TABLE visitor_visits ADD CONSTRAINT FK_visits_visitor_id FOREIGN KEY (visitor_id) REFERENCES visitors(id);
PAGE_VIEWS logs individual page views (not all pages, just pages we are tracking). It can be linked to a visitor and can reference a visitor_visit (current count 2.4million -- reason it is higher is we started micro-visitor logging after logging individual pages). An insert/on duplicate query is used to add the record to this based on the view_date for the identified user. Since the ID is not needed, a pure lookup query isnt required
CREATE TABLE page_views (
id int(10) UNSIGNED NOT NULL auto_increment,
page_id int(10) UNSIGNED NOT NULL,
current_donations decimal(10,2) NOT NULL DEFAULT 0,
ip varchar(25) NOT NULL,
hash varchar(32) NOT NULL,
visitor_id int(10) UNSIGNED NULL DEFAULT NULL AFTER,
visitor_visit_id int(10) UNSIGNED NULL DEFAULT NULL AFTER,
page_views int(10) UNSIGNED NOT NULL DEFAULT 0,
widget_views int(10) UNSIGNED NOT NULL DEFAULT 0,
view_date date NOT NULL,
viewed_at datetime NOT NULL default '0000-00-00 00:00:00',
created_at datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE page_views ADD UNIQUE INDEX (page_id,view_date,visitor_id,hash);
ALTER TABLE page_views ADD INDEX (visitor_id);
ALTER TABLE page_views ADD INDEX (visitor_visit_id);
ALTER TABLE page_views ADD CONSTRAINT FK_page_views_page_id FOREIGN KEY (page_id) REFERENCES pages(id);
ALTER TABLE page_views ADD CONSTRAINT FK_page_views_visitor_id FOREIGN KEY (visitor_id) REFERENCES visitors(id);
ALTER TABLE page_views ADD CONSTRAINT FK_page_views_visit_id FOREIGN KEY (visitor_visit_id) REFERENCES visitor_visits(id);
Last week, our site got a inflow of people due to a news article, and this visitor identifying rall bottlenecked performance. I am wondering if there is an obvious optimization in there. Could it be the foreign key constraints ? Over indexing? Need for better indexing?
Try this ::
1) Index on varchar doesn't much improve the performance.
2) Try to partition the table, on a date range.
You didn't tell us what is bottlenecking your database, so I just guess it's InnoDB concurrent writes. If it isn't so and the problem is only with SELECTs (which I doubt), you should show us the exact queries. You could try to reduce the write performance hit by creating a staging table and then bulk-moving stuff from in to the main table:
CREATE TABLE page_views_tmp (
id int(10) UNSIGNED NOT NULL auto_increment,
page_id int(10) UNSIGNED NOT NULL,
current_donations decimal(10,2) NOT NULL DEFAULT 0,
ip varchar(25) NOT NULL,
hash varchar(32) NOT NULL,
visitor_id int(10) UNSIGNED NULL DEFAULT NULL AFTER,
visitor_visit_id int(10) UNSIGNED NULL DEFAULT NULL AFTER,
page_views int(10) UNSIGNED NOT NULL DEFAULT 0,
widget_views int(10) UNSIGNED NOT NULL DEFAULT 0,
view_date date NOT NULL,
viewed_at datetime NOT NULL default '0000-00-00 00:00:00',
created_at datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
) ENGINE=MEMORY DEFAULT CHARSET=utf8;
And then, once per a couple of seconds or after this table has a considerable amount of rows in it:
START TRANSACTION;
INSERT INTO page_views SELECT * FROM page_views_tmp;
DELETE FROM page_views_tmp;
COMMIT;