I'm trying to execute the following query via the "Run SQL query/queries on database" page in phpmyadmin:
CREATE TABLE IF NOT EXISTS `bindings` (
`binding_id` int(10) unsigned NOT NULL auto_increment,
`game_id` smallint(5) unsigned NOT NULL,
`layout_id` tinyint(3) unsigned NOT NULL,
`key_number` tinyint(3) unsigned NOT NULL,
`normal_action` varchar(128) default NULL,
`normal_group` tinyint(2) unsigned default NULL,
`shift_action` varchar(64) default NULL,
`shift_group` tinyint(2) unsigned default NULL,
`ctrl_action` varchar(64) default NULL,
`ctrl_group` tinyint(2) unsigned default NULL,
`alt_action` varchar(64) default NULL,
`alt_group` tinyint(2) unsigned default NULL,
`altgr_action` varchar(64) default NULL,
`altgr_group` tinyint(2) unsigned default NULL,
`extra_action` varchar(64) default NULL,
`extra_group` tinyint(2) unsigned default NULL,
`image_file` varchar(256) default NULL,
PRIMARY KEY (`binding_id`),
KEY `fk_layout_id` (`layout_id`),
KEY `fk_game_id` (`game_id`),
KEY `idx_combined_bindings` (`game_id`,`layout_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=11150 ;
The result is a green box and checkmark saying the query was executed successfully. However phpmyadmin still reports "No tables found in database". What is wrong with the query or the database? Thanks!
Note: the above query is part of a much larger dump that I want to import into the database.
Never mind. I dropped the database and started over with a blank one and everything is running fine now. Somehow things got messed up when my web host upgraded from mySQL 5.0.92 to mySQL 5.1.63. Sorry!
Related
I'm getting very slow response running a very simple query in a small table (115k records)...
It takes about 8sec to respond, and I can't figure out why it's taking that long. Any advice would be awesome
Table:
CREATE TABLE `financeiro_fluxo` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`branch` int(10) unsigned NOT NULL,
`abertura` int(10) DEFAULT NULL,
`origem` int(10) unsigned DEFAULT NULL,
`status_pagamento` tinyint(3) unsigned DEFAULT NULL,
`conta` int(10) unsigned NOT NULL,
`tipo_lancamento` tinyint(3) unsigned NOT NULL,
`categoria` int(10) unsigned NOT NULL,
`tipo_entidade` varchar(32) COLLATE utf8_unicode_ci NOT NULL,
`entidade` int(10) unsigned DEFAULT NULL,
`entidade_input` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`tipo_pagamento` tinyint(3) unsigned NOT NULL,
`parcela` smallint(5) unsigned NOT NULL,
`parcelas` smallint(5) unsigned NOT NULL,
`valor` decimal(12,2) NOT NULL,
`valor_taxa` decimal(12,2) DEFAULT NULL,
`valor_troco` decimal(12,2) DEFAULT NULL,
`confirmado` tinyint(3) unsigned DEFAULT NULL,
`data_confirmacao` datetime DEFAULT NULL,
`vencimento` date NOT NULL,
`info` varchar(510) COLLATE utf8_unicode_ci DEFAULT NULL,
`bandeira` int(10) unsigned DEFAULT NULL,
`user_add` int(10) unsigned NOT NULL,
`user_last` int(10) unsigned NOT NULL,
`param_ref` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`param` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`file` int(10) unsigned DEFAULT NULL,
`date_created` datetime NOT NULL,
`date_modified` datetime NOT NULL,
`status` smallint(6) unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=116749 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Query:
SELECT * from financeiro_fluxo
Explain:
id select_type table type key key_len rows
1 SIMPLE financeiro_fluxo ALL 116244
The same query running on localhost with the same table, returns in less than a sec...
Profile:
Seems you are doing a full table scan because your query does not include any limiting conditions (for example WHERE clause or LIMIT). To let the query preform better use indexed columns with some kind of criteria. What happens if you add WHERE id IS NOT NULL
I assume you need all the records, if not limit the result set by added conditions in a more specific WHERE clause (on a indexed column) or a LIMIT clause.
Will the "reports" aggregate data? Of so, you could speed up the 8 second (remote) query by doing more work in the server, thereby shipping less data across the wire.
That is, think about whether AVG(..), COUNT(*), SUM(..), MAX(..), etc can be done in the SELECT.
Taking that another step... Build and maintain a "Summary table" that has subtotals (etc). Then, reading (or scanning) the summary table and summing up the subtotals, etc, will be even faster, both in the Server and across the wire.
(And I agree with the need to avoid *, and that the 8 seconds is probably due to network delay (and "bandwidth"). Where is the server geographically? How long does SELECT 1; take?)
I'm trying to run the following command in the command line terminal of MySql, on my backup server:
Table Schema :
CREATE TABLE `cadveiculoequip` (
`idveiculoequip` VARCHAR(36) NOT NULL,
`idveiculo` VARCHAR(36) DEFAULT NULL,
`idequipamento` VARCHAR(36) DEFAULT NULL,
`datainstalacao` DATE DEFAULT NULL,
`datadesinstalacao` DATE DEFAULT NULL,
`idchkheader` VARCHAR(36) DEFAULT NULL,
`ID` INT(11) DEFAULT NULL,
`lastupdate` TIMESTAMP NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
`primario` INT(1) NOT NULL DEFAULT '1',
`mapeia_sombra` INT(1) DEFAULT '0',
`tec_responsavel` VARCHAR(100) DEFAULT NULL,
`km_rodado` VARCHAR(100) DEFAULT NULL,
`situacao` INT(2) DEFAULT NULL,
`teclado` VARCHAR(36) DEFAULT NULL,
`rfid` VARCHAR(36) DEFAULT NULL,
`idsatelite` VARCHAR(36) DEFAULT NULL,
`telemetria` VARCHAR(10) DEFAULT NULL,
`idosdes` VARCHAR(36) DEFAULT NULL,
PRIMARY KEY (`idveiculoequip`)
) ENGINE=INNODB DEFAULT CHARSET=utf8 AVG_ROW_LENGTH=129;
Query is :
INSERT INTO `cadveiculoequip` (`idveiculoequip`,`idveiculo`,`idequipamento`,`datainstalacao`,`datadesinstalacao`,`idchkheader`,`ID`,`lastupdate`,`primario`,`mapeia_sombra`,`tec_responsavel`,`km_rodado`,`situacao`,`teclado`,`rfid`,`idsatelite`,`telemetria`,`idosdes`)
VALUES ('IGORM','6788103A-8109-430C-A131-9FBBAF6D01F3','8abef011-c107-11df-b983-68b5558ab3e2','2018-02-21',NULL,'2CA923B6-60E9-42CF-BCFB-4BA238263079',4257329,'2018-02-21 08:44:51',1,0,'IGORM','0',1,NULL,NULL,NULL,'',NULL);
After execute the command, i just receive the message "0 rows affected".
Okay, so what's the problem..? I have executed the exactly same command in my development server (identical to backup server) the command has executed successfully, besides has returned "1 rows affected".
I discard the idea of being a MySQL Error 1064.. Does anyone know what it could be?
(Sorry about the bad english, I'm kind of rusty... hehehe)
Edit:
Table 'cadveiculoequip'
I have a client that is describing an occurrence when they are adding new data from a web form. If the submitted data matches any existing database entries, the system deletes the existing entry.
I've checked the scripts and I don't see a DELETE query that would affect the related table. There are UPDATE queries, none of which affect a field in the DB indicating a deletion or marked as deleted.
Are there ways data could be lost without the execution of a DELETE query?
As asked for, here's the "create table" statement:
CREATE TABLE `msp_zip_codes`
(
`zip_code` varchar(5) DEFAULT NULL,
`city` varchar(35) DEFAULT NULL,
`state_prefix` varchar(2) DEFAULT NULL,
`county` varchar(45) DEFAULT NULL,
`area_code` varchar(45) DEFAULT NULL,
`CityType` varchar(1) DEFAULT NULL,
`CityAliasAbbreviation` varchar(13) DEFAULT NULL,
`CityAliasName` varchar(35) DEFAULT NULL,
`lat` decimal(18,6) DEFAULT NULL,
`lon` decimal(18,6) DEFAULT NULL,
`time_zone` varchar(7) DEFAULT NULL,
`Elevation` int(10) DEFAULT NULL,
`CountyFIPS` varchar(5) DEFAULT NULL,
`DayLightSaving` varchar(1) DEFAULT NULL,
`PreferredLastLineKey` varchar(25) DEFAULT NULL,
`ClassificationCode` varchar(2) DEFAULT NULL,
`MultiCounty` varchar(1) DEFAULT NULL,
`StateFIPS` varchar(2) DEFAULT NULL,
`CityStateKey` varchar(6) DEFAULT NULL,
`CityAliasCode` varchar(5) DEFAULT NULL,
`PrimaryRecord` varchar(50) DEFAULT NULL,
`CityMixedCase` varchar(50) DEFAULT NULL,
`CityAliasMixedCase` varchar(50) DEFAULT NULL,
KEY `AreaCode` (`area_code`),
KEY `CityAliasCode` (`CityAliasCode`),
KEY `CityStateKey` (`CityStateKey`),
KEY `ClassificationCode` (`ClassificationCode`),
KEY `PreferredLastLineKey` (`PreferredLastLineKey`),
KEY `ZipCode` (`zip_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
One of the possibilities is that the table has an UPDATE TRIGGER set which fires every time there's an update. Or the other one, there's an Event Scheduler running on the server.
Code to show all triggers on the database:
SELECT *
FROM INFORMATION_SCHEMA.TRIGGERS a
WHERE a.TRIGGER_SCHEMA LIKE CONCAT('%', 'databaseNameHERE', '%')
Code to show all events on the database:
SHOW EVENTS FROM databaseNameHERE;
MySQL MyISAM database which currently has 2,280 rows in a table has locked up twice in the past 6 months or so.
When trying to add a new row it says "Primary key already used", when the next increment value is higher than the last id in the table. Seems to fix itself when I reset the auto increment.
Database is for a site which gets around 200+ hits a day, peak of about 25-20 an hour, so can't imagine it's due to overload on the database.
Trying to figure out why this keeps happening and if I can fix the issue so the client doesn't have to keep calling up whenever they can't add a new article to their site.
EDIT: Just to preempt potential comments, I realise that the table and code are not ideal, but I'm not looking for ways I should improve this, unless it's the root cause of the problem, poor performance/security I can live with (just), but I do need to figure out what could be causing it to lock the table. Thanks.
Table Definition
CREATE TABLE `articles` (
`article_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`article_meta_desc` text,
`article_meta_keyw` text,
`article_title` varchar(255) DEFAULT NULL,
`article_date` int(10) unsigned DEFAULT NULL,
`article_intro` text,
`article_embed` text,
`article_content` text,
`article_sector` varchar(255) DEFAULT NULL,
`article_type` varchar(255) DEFAULT NULL,
`article_ma` tinyint(1) unsigned DEFAULT NULL,
`article_pn` tinyint(1) unsigned DEFAULT NULL,
`article_cw` tinyint(1) unsigned DEFAULT NULL,
`article_er` tinyint(1) unsigned DEFAULT NULL,
`article_kr` tinyint(1) unsigned DEFAULT NULL,
`article_rc` tinyint(1) unsigned DEFAULT NULL,
`article_rs` tinyint(1) DEFAULT NULL,
`article_img_s` varchar(255) DEFAULT NULL,
`article_img_l` varchar(255) DEFAULT NULL,
`article_link` varchar(255) DEFAULT NULL,
`article_highlight` int(10) unsigned DEFAULT NULL,
`article_slug` text,
`article_alias` text,
`article_hide` smallint(1) unsigned NOT NULL DEFAULT '0',
`article_ad_layout` tinyint(1) unsigned DEFAULT '0',
`article_ad_banner` smallint(5) unsigned DEFAULT NULL,
`article_ad_sky` smallint(5) unsigned DEFAULT NULL,
`article_ad_square1` smallint(5) unsigned DEFAULT NULL,
`article_ad_square2` smallint(5) unsigned DEFAULT NULL,
`article_ad_square3` smallint(5) unsigned DEFAULT NULL,
`article_newswire` smallint(1) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`article_id`),
FULLTEXT KEY `full_text` (`article_title`,`article_intro`,`article_content`)
) ENGINE=MyISAM AUTO_INCREMENT=2384 DEFAULT CHARSET=latin1 CHECKSUM=1 DELAY_KEY_WRITE=1 ROW_FORMAT=DYNAMIC;
_ma,_pn,_cw,_er,_kr,_rc,_rs are used for showing which category articles are for. Please ignore the bad use of a table for the ads and section, site was made quite a long time ago, I have learnt better since :p
Insert statement
INSERT INTO articles (article_id, article_meta_desc, article_meta_keyw, article_title, article_date, article_intro, article_embed, article_content, article_sector, article_type, article_ma, article_pn, article_cw, article_er, article_kr, article_rc, article_rs, article_img_s, article_img_l, article_link, article_highlight, article_slug, article_alias, article_hide)
VALUES ('','$insert_article_meta_desc','$insert_article_meta_keyw','$insert_article_title','$insert_article_date','$insert_article_intro','$insert_article_embed','$insert_article_content','$insert_article_sector','$insert_article_category','$insert_article_ma','$insert_article_pn','$insert_article_cw','$insert_article_er','$insert_article_kr','$insert_article_rc','$insert_article_rs','$insert_article_img_s','$insert_article_img_l','','$insert_article_highlight','$insert_article_slug','','$insert_article_hide')
Again, old site, please forgive me. Not sure if it's something to do with doing an insert that sets the id to '' which would then be set to the next increment value, could this cause problems?
Try taking out the article_id field name, and first '' in the values, from the INSERT stmt; the auto increment ID should get allocated automatically.
I've a table with around 6-7lacs records and it's going to grow as time passes.It has around 16-20 columns in it. There are no one-many relationship to any of these columns.
User data entries are stored in these table.
So would it be feasible to split my table into multiple small tables or else just split the table into 2 halfs one with all the entries in it and other the recently fresh records which would be present to the data entry operators to feed in their entries.
In short my question is whether the mysql execution time would be faster if I split the tables, or would it be faster if I split them into two half's.
I guess the latter would be more feasible since it would not perform any join queries.
Updated:
CREATE TABLE `images` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`primary_category_id` int(10) unsigned DEFAULT NULL,
`secondary_category_id` int(10) unsigned DEFAULT NULL,
`front_url` varchar(255) DEFAULT NULL,
`back_url` varchar(255) DEFAULT NULL,
`title` varchar(100) DEFAULT NULL,
`part` varchar(10) DEFAULT NULL,
`photo_id` int(10) unsigned DEFAULT NULL,
`photo_dt_month` varchar(2) DEFAULT NULL,
`photo_dt_day` varchar(2) DEFAULT NULL,
`photo_dt_yr` varchar(4) DEFAULT NULL,
`type` varchar(25) DEFAULT NULL,
`size_width` int(10) unsigned DEFAULT NULL,
`size_height` int(10) unsigned DEFAULT NULL,
`dpi` int(10) unsigned NOT NULL DEFAULT '0',
`dpix` int(10) unsigned DEFAULT NULL,
`dpiy` int(10) unsigned DEFAULT NULL,
`in_stock` varchar(50) DEFAULT NULL,
`outlet` varchar(50) DEFAULT NULL,
`source` varchar(50) DEFAULT NULL,
`keywords` varchar(255) DEFAULT NULL,
`emotional_keywords` varchar(255) DEFAULT NULL,
`mechanical_keywords` varchar(255) DEFAULT NULL,
`description` text,
`notes` text,
`comments` text,
`exported_to_ebay_dt` datetime DEFAULT NULL,
`exported_to_ebay` set('Y','N') NOT NULL DEFAULT 'N',
`updated_worker_id` int(10) unsigned DEFAULT NULL,
`updated_worker_dt` datetime DEFAULT NULL,
`locked_worker_id` int(10) unsigned DEFAULT NULL,
`locked_worker_dt` datetime DEFAULT NULL,
`updated_admin_id` int(10) unsigned DEFAULT NULL,
`updated_admin_dt` datetime DEFAULT NULL,
`added_dt` datetime DEFAULT NULL,
`updated_manager_id` int(10) unsigned DEFAULT NULL,
`updated_manager_dt` datetime DEFAULT NULL,
`manager_review` set('Y','N') NOT NULL DEFAULT 'N',
`paid_status` set('Y','N') NOT NULL DEFAULT 'N',
`exported_to_web_dt` datetime DEFAULT NULL,
`exported_to_web` set('Y','N') DEFAULT 'N',
`prefix` varchar(50) DEFAULT NULL,
`is_premium` set('Y','N') DEFAULT 'N',
`template` varchar(50) DEFAULT 'HIPE_default',
`photographer` varchar(100) DEFAULT NULL,
`copyright` varchar(100) DEFAULT NULL,
`priority` int(4) DEFAULT '1',
`step` set('1','2') DEFAULT '1',
PRIMARY KEY (`id`),
UNIQUE KEY `part` (`part`),
KEY `primary_category_id` (`primary_category_id`),
KEY `updated_worker_id` (`updated_worker_id`),
KEY `updated_worker_dt` (`updated_worker_dt`)
) ENGINE=MyISAM AUTO_INCREMENT=1013687 DEFAULT CHARSET=latin1
The above is my table structure.After there are entries being made say around 1lac I would split it into another table say images_history with same structure.Is this feasible or should I split them into multiple tables to reduce the query execution time
Why do you want to split the table? It would lead to a ton of extra code and slow down the execution time by adding extra queries if you still want to access both of the new tables. (If one of the tables are going to store rarely used previous versions of records of the images table - i.e. version control - it may still be a good idea).
Before even thinking about splitting the table, see if you can increase performance by optimizing the existing code by making sure none of the following performance disasters are:
Do all SELECTs filter by PRIMARY KEY?
Is the index cache large enough to hold all indices in the computers RAM?
Are any string matching SELECTs with LIKE using the indices? I.e. only exact matches or wildcards on the right, never on the left (e.g. "searchword%" and never "%searchword"
Are there any slow performing queries that use SELECT * instead of selecting only the columns you need?
Have you avoided using OR in SELECTs?
Performing queries on a table with 700 000 records shouldn't be slow if tabels are properly indexed and queries are actually using those indices.