So for some reason my Mysql table always returns an empty set
mysql> show table status like 'test_table';
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
| test_table | InnoDB | 10 | Compact | 1625218 | 749 | 1218363392 | 0 | 0 | 1234173952 | NULL | 2015-07-25 12:03:40 | NULL | NULL | utf8mb4_unicode_ci | NULL | | |
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+------------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
1 row in set (0.00 sec)
mysql> select * from test_table;
Empty set (0.00 sec)
mysql>
Any advice on how I can debug this?
Here's the create table
| test_table | CREATE TABLE `test_table` (
`export_date` bigint(20) DEFAULT NULL,
`id` int(11) NOT NULL DEFAULT '0',
`title` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`recommended_age` varchar(20) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`artist_name` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`seller_name` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`company_url` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`support_url` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`view_url` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`artwork_url_large` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`artwork_url_small` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`release_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
Turns out it was an import problem. I imported my data with a Python script and didn't have autocommit set to true (the script was written for an older version of MYSQL)
Its possibly the mySQL server does not know which database you are searching and is defaulting to the default schema where the table doesnt exist?
Try using the USE verb with your database name.
eg: if your database was named db1 and your table was mytable.
USE db1;
SELECT * FROM mytable;
# selects from db1.mytable
It is possible that your data is not flush properly in to the table, run flush table by the following command and then check again.
FLUSH TABLES;
Related
My table consist of 600K records. The below queries have been troubling me for a while.
DDL:
CREATE TABLE `cvprofiles` (
`tid` bigint(20) NOT NULL AUTO_INCREMENT,
`partnerId` bigint(20) DEFAULT '0' COMMENT 'resume owner',
`tenant` bigint(20) DEFAULT '0' COMMENT 'sellercompany',
`lngId` int(4) DEFAULT '0',
`firstName` varbinary(150) DEFAULT '',
`lastName` varbinary(150) DEFAULT '',
`profilePicture` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT '',
`mobileIsd` varchar(20) COLLATE utf8mb4_unicode_ci DEFAULT '',
`mobileNumber` varbinary(80) DEFAULT '',
`emailId` varbinary(250) DEFAULT '',
`altEmailId` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`cvPath` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT '',
`cvFileName` varchar(250) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`genderCode` int(4) DEFAULT '0',
`dob` date DEFAULT NULL,
`presentLocation` varchar(350) COLLATE utf8mb4_unicode_ci DEFAULT '',
`presentLocationId` bigint(20) DEFAULT NULL,
`countryId` bigint(20) DEFAULT '0' COMMENT 'country to be maintained',
`latitude` decimal(19,15) DEFAULT '0.000000000000000',
`longitude` decimal(19,15) DEFAULT '0.000000000000000',
`totalExp` decimal(5,2) DEFAULT '0.00',
`anyKeywords` varchar(4000) COLLATE utf8mb4_unicode_ci DEFAULT '',
`cvKeywords` mediumtext COLLATE utf8mb4_unicode_ci,
`presentEmployer` varchar(400) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`noticePeriod` int(4) DEFAULT '0',
`presentSalaryCurrId` bigint(20) DEFAULT '0',
`crDate` datetime DEFAULT NULL,
`crUserId` bigint(20) DEFAULT '0',
`luDate` datetime DEFAULT NULL,
`luUserId` bigint(20) DEFAULT '0',
`skillKeywords` text COLLATE utf8mb4_unicode_ci,
`industryKeywords` varchar(2000) COLLATE utf8mb4_unicode_ci DEFAULT '',
`certiKeywords` varchar(2000) COLLATE utf8mb4_unicode_ci DEFAULT '',
`prefLocKeywords` varchar(2000) COLLATE utf8mb4_unicode_ci DEFAULT '',
`educationKeywords` varchar(2000) COLLATE utf8mb4_unicode_ci DEFAULT '',
`roleKeywords` tinytext COLLATE utf8mb4_unicode_ci,
`abilityKeywords` text COLLATE utf8mb4_unicode_ci,
`lngKeywords` text COLLATE utf8mb4_unicode_ci,
`infoKeywords` varchar(600) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT 'combination of fn,ln,mno,email,present employer designation',
`jobTitleId` bigint(20) DEFAULT NULL,
`source` bigint(6) DEFAULT NULL,
`portalUid` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`salutationId` int(5) DEFAULT NULL,
PRIMARY KEY (`tid`),
KEY `partnerId` (`partnerId`),
KEY `crDate` (`crDate`),
KEY `idx_cvprofiles_firstName` (`firstName`),
KEY `idx_cvprofiles_mobileIsd` (`mobileIsd`),
KEY `idx_cvprofiles_mobileNumber` (`mobileNumber`),
KEY `idx_cvprofiles_emailId` (`emailId`),
KEY `idx_cvprofiles_dob` (`dob`),
KEY `luDate` (`luDate`),
KEY `idx_s_p_m_e` (`tenant`,`partnerId`,`mobileNumber`,`emailId`),
KEY `idx_s_f_l_c_s` (`tenant`,`firstName`,`lastName`,`crDate`),
KEY `sel` (`tenant`),
KEY `c_c` (`crDate`,`crUserId`),
FULLTEXT KEY `fx_cat` (`skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,`abilityKeywords`,`lngKeywords`,`roleKeywords`,`industryKeywords`,`educationKeywords`,`prefLocKeywords`)
) ;
Query1: Below fulltext query takes "0.43 sec" for word "java" :
select count(*)
from cvprofiles
where match(`skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,
`abilityKeywords`,`lngKeywords`,`roleKeywords`,
`industryKeywords`,`educationKeywords`,`prefLocKeywords`)
against ('java' in boolean mode);
Result: 168944 records
Explain:
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
Query2:
select count(*) from cvprofiles where tenant=429;
Response time: 0.18 sec , Result : 845 records
Explain:
+----+-------------+-----------------+------------+------+-------------------------------+------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------------+------------+------+-------------------------------+------+---------+-------+------+----------+-------------+
| 1 | SIMPLE | icrd_resumeBank | NULL | ref | idx_s_p_m_e,idx_s_f_l_c_s,sel | sel | 9 | const | 845 | 100.00 | Using index |
Query3: Combine fulltext with integer field takes more then 45 sec+.
select count(*)
from cvprofiles
where match(`skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,
`abilityKeywords`,`lngKeywords`,`roleKeywords`,
`industryKeywords`,`educationKeywords`,`prefLocKeywords`)
against ('java' in boolean mode)
and tenant=429;
Response time: 40.12 sec, Result : 452 records
Explain:
+----+-------------+-----------------+------------+----------+--------------------------------------+--------+---------+-------+------+----------+-----------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------------+------------+----------+--------------------------------------+--------+---------+-------+------+----------+-----------------------------------+
| 1 | SIMPLE | icrd_resumeBank | NULL | fulltext | idx_s_p_m_e,idx_s_f_l_c_s,sel,fx_cat | fx_cat | 0 | const | 1 | 5.00 | Using where; Ft_hints: no_ranking |
+----+-------------+-----------------+------------+----------+--------------------------------------+--------+---------+-------+------+----------+-----------------------------------+
None of the combinations of the query are working. How to improve performance of the query of fulltext with integer fields?
Using MySQL version: 5.7
Storage Engine: InnoDB
The Optimizer is caught between a rock and a hard place --
whether to use the FULLTEXT index, then filter out those with the wrong tenant. (This is probably faster, and the formulation below may trick it into using it.)
Or to start by fetching on tenant first, then do the FULLTEXT tests. (Please provide SHOW CREATE TABLE cvprofiles so we can see if this is even viable.)
This kludge may make it run faster:
select count(*)
from cvprofiles
where match(`skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,
`abilityKeywords`,`lngKeywords`,`roleKeywords`,
`industryKeywords`,`educationKeywords`,`prefLocKeywords`)
against ('java' in boolean mode)
HAVING tenant=429;
The CREATE TABLE may point out flaws in the schema that led to slugishness.
On second thought, my kludge may not help in this case. It will fetch 168944 rows, then reach into the table to check that many value of tenant; this will be 168944 random lookups. The speed of that depends on disk type (SSD vs HDD) and size of innodb_buffer_pool_size. So, which disk type and what is that setting, plus how much RAM on the server?
Where I am going with the previous paragraph... If cache space is tight, it will be slow.
This looks like a case where "index merge intersect" would be useful, but the EXPLAIN says it did not try that. So,... Consider filing a bug report at bugs.mysql.com .
Hard to say without the EXPLAIN statement and table indexes, however most likely MySQL is making a huge temporary table to store the result of the first match and then tries the second filter.
I would recommend setting the 'tenant=429' part as a subquery instead.
select count(*) from
( SELECT `skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,`abilityKeywords`,`lngKeywords`,`roleKeywords`,`industryKeywords`,`educationKeywords`,`prefLocKeywords`
from cvprofiles
where tenant=429
) AS x
WHERE match(`skillKeywords`,`anyKeywords`,`cvKeywords`,`infoKeywords`,`abilityKeywords`,`lngKeywords`,`roleKeywords`,`industryKeywords`,`educationKeywords`,`prefLocKeywords`)
against ('java' in boolean mode) ;
Note that you will most likely need to name the columns in the subquery and access that that way.
I want to ask about MySql float format. I tried to insert float value for example 12345.66 and it inserted without error and the value is exactly the same. but if i tried to insert value like 12345.01, value inserted is like this 12345.00. I have tried any value that have .0* and it always inserted as .00. Why is that happend?
I tried both using MYSQL from terminal and from phpmyadmin.
sorry for my bad english.
here is my MYSQL version:
+-------------------------+-------------------------+
| Variable_name | Value |
+-------------------------+-------------------------+
| innodb_version | 5.7.23 |
| protocol_version | 10 |
| slave_type_conversions | |
| tls_version | TLSv1,TLSv1.1 |
| version | 5.7.23-0ubuntu0.16.04.1 |
| version_comment | (Ubuntu) |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
+-------------------------+-------------------------+
Here is my create table. all that float have the same problem.
CREATE TABLE `angsurantempo` (
`ID` varchar(20) COLLATE utf8_unicode_ci NOT NULL,
`NoPA` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`Periode` int(11) NOT NULL,
`TglEfektif` datetime NOT NULL,
`Pokok` float(18,2) NOT NULL,
`Bunga` float(18,2) NOT NULL,
`Denda` float(18,2) NOT NULL,
`Hari` int(11) NOT NULL,
`TglPost` datetime NOT NULL,
`LogPost` varchar(25) COLLATE utf8_unicode_ci NOT NULL,
`IDKop` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`ID`,`IDKop`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
My Insert Query:
INSERT INTO angsurantempo VALUES ('11372','PA-201708-002','15','2017-08-26 00:00:00','1882755.08','2261277.05','0','31','2017-08-30 15:16:00','PAA-201708-007','MAS1')
This MYSQL server is installed in VPS Ubuntu
You can use decimal(7,2) data type to store exact decimal value.
IF you want to insert 12345.01, it is impossible
I don't think you can place comma(,) after the decimal point
You should change the data type of that field in the table from float to double with this command
ALTER TABLE your_table_name
MODIFY your_column_name DOUBLE NOT NULL;
Can I use UTF-8 names in column name on data base? Like example here:
$zapytaj = mysql_query("SELECT * FROM users WHERE `użytkownicy` = '$nazwaużytkownika' ");
This give me error:
Unknown column 'użytkownicy' in 'where clause'
Can someone explain why this is not working?
mysql> SHOW VARIABLES LIKE 'character%';
+--------------------------+-------------
| Variable_name | Value
+--------------------------+-------------
| character_set_client | utf8mb4
| character_set_connection | utf8mb4
| character_set_database | utf8mb4
| character_set_filesystem | binary
| character_set_results | utf8mb4
| character_set_server | latin1
| character_set_system | utf8
mysql> SELECT COLUMN_NAME, HEX(COLUMN_NAME)
FROM information_schema.columns WHERE table_name = "so31349641";
+--------------+--------------------------+
| COLUMN_NAME | HEX(COLUMN_NAME) |
+--------------+--------------------------+
| id | 6964 |
| użytkownicy | 75C5BC79746B6F776E696379 | -- Note the C5BC for ż
| hasło | 686173C5826F | -- and the C582 for ł
+--------------+--------------------------+
If I delete `` from użytkownicy I see this error:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '�ytkownicy = 'xxx'' at line 1
Maybe PHP file are don't have UTF8 coding? How to check this file in PHPStorm?
!SOLUTION!
If You have this error just change mysql to PDO that should fix Your problem.
To answer your stated question, column names are utf8:
mysql> SHOW CREATE TABLE information_schema.columns\G
*************************** 1. row ***************************
Table: COLUMNS
Create Table: CREATE TEMPORARY TABLE `COLUMNS` (
`TABLE_CATALOG` varchar(512) NOT NULL DEFAULT '',
`TABLE_SCHEMA` varchar(64) NOT NULL DEFAULT '',
`TABLE_NAME` varchar(64) NOT NULL DEFAULT '',
`COLUMN_NAME` varchar(64) NOT NULL DEFAULT '', -- NOTE --
`ORDINAL_POSITION` bigint(21) unsigned NOT NULL DEFAULT '0',
`COLUMN_DEFAULT` longtext,
`IS_NULLABLE` varchar(3) NOT NULL DEFAULT '',
`DATA_TYPE` varchar(64) NOT NULL DEFAULT '',
`CHARACTER_MAXIMUM_LENGTH` bigint(21) unsigned DEFAULT NULL,
`CHARACTER_OCTET_LENGTH` bigint(21) unsigned DEFAULT NULL,
`NUMERIC_PRECISION` bigint(21) unsigned DEFAULT NULL,
`NUMERIC_SCALE` bigint(21) unsigned DEFAULT NULL,
`DATETIME_PRECISION` bigint(21) unsigned DEFAULT NULL,
`CHARACTER_SET_NAME` varchar(32) DEFAULT NULL,
`COLLATION_NAME` varchar(32) DEFAULT NULL,
`COLUMN_TYPE` longtext NOT NULL,
`COLUMN_KEY` varchar(3) NOT NULL DEFAULT '',
`EXTRA` varchar(30) NOT NULL DEFAULT '',
`PRIVILEGES` varchar(80) NOT NULL DEFAULT '',
`COLUMN_COMMENT` varchar(1024) NOT NULL DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=utf8
To get to the root of the implied question ("Why does the query fail"), let's see
SHOW VARIABLES LIKE 'character%';
Edit
Well, something un-obvious going on. This works for me:
mysql> create table so31349641 (
id int(11) NOT NULL AUTO_INCREMENT,
użytkownicy varchar(24) NOT NULL,
hasło varchar(24) NOT NULL, PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
mysql> INSERT INTO so31349641 VALUES (1, 'a', 'b');
mysql> SELECT * FROM so31349641 WHERE użytkownicy = 'a';
+----+--------------+--------+
| id | użytkownicy | hasło |
+----+--------------+--------+
| 1 | a | b |
+----+--------------+--------+
This seems ordinary:
mysql> SHOW VARIABLES LIKE 'character%';
+--------------------------+-------------
| Variable_name | Value
+--------------------------+-------------
| character_set_client | utf8
| character_set_connection | utf8
| character_set_database | latin1
| character_set_filesystem | binary
| character_set_results | utf8
| character_set_server | latin1
| character_set_system | utf8
Looking in the IS:
mysql> SELECT COLUMN_NAME, HEX(COLUMN_NAME)
FROM information_schema.columns WHERE table_name = "so31349641";
+--------------+--------------------------+
| COLUMN_NAME | HEX(COLUMN_NAME) |
+--------------+--------------------------+
| id | 6964 |
| użytkownicy | 75C5BC79746B6F776E696379 | -- Note the C5BC
| hasło | 686173C5826F | -- and the C582 for ł
+--------------+--------------------------+
That is as I would expect it.
My char% values are different than yours, but I think we are both "OK" for this situation.
Try a SELECT on the information_schema similar to what I did.
Next, what is your client? PHP? Something else? Perhaps the encoding is incorrect in the client.
(Rather than trying to use HTML tags in a Comment, Edit your original question with the added info.)
It looks like UTF-8 in SQL is not default, but tables/databases can be changed to be so.
Some potentially helpful links:
The mySQL documentation on charsets:
https://dev.mysql.com/doc/refman/5.0/en/charset.html
A SO question on determining the charset:
determining the character set of a table / database?
On changing the charset: http://makandracards.com/makandra/2529-show-and-change-mysql-default-character-set
Hope this helps.
Why is the below query failing it use the index story_id, in the story_keywords table?
mysql> EXPLAIN SELECT `stories`.*
-> FROM (`stories`)
-> JOIN `story_keywords` ON `story_keywords`.`story_id` = `stories`.`id`
-> WHERE `image_full_url` != ''
-> AND `order` != 0
-> AND `news_type` IN ('movie', 'movie_review')
-> AND `keyword` IN ('topnews', 'toptablet')
-> GROUP BY `stories`.`id`
-> ORDER BY `created` DESC, `order` DESC
-> LIMIT 5 ;
+----+-------------+----------------+--------+---------------+---------+---------+---------------------------------------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------------+--------+---------------+---------+---------+---------------------------------------+------+----------------------------------------------+
| 1 | SIMPLE | story_keywords | ALL | story_id | NULL | NULL | NULL | 42 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | stories | eq_ref | PRIMARY | PRIMARY | 767 | entertainment.story_keywords.story_id | 1 | Using where |
+----+-------------+----------------+--------+---------------+---------+---------+---------------------------------------+------+----------------------------------------------+
2 rows in set (0.00 sec)
mysql> show create table stories;
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| stories | CREATE TABLE `stories` (
`id` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`news_type` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`title` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`created` datetime DEFAULT NULL,
`author` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`author_title` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`image_caption` text COLLATE utf8_unicode_ci,
`image_credit` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`image_full_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`body` text COLLATE utf8_unicode_ci,
`summary` text COLLATE utf8_unicode_ci,
`external_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`order` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci |
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show create table story_keywords;
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| story_keywords | CREATE TABLE `story_keywords` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`story_id` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`keyword` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`),
KEY `story_id` (`story_id`)
) ENGINE=MyISAM AUTO_INCREMENT=85 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
It is probably because MySQL believes it is cheaper to fetch ALL rows from story_keywords table and JOIN them in instead of using indexes. It sounds weird at first, but, you see, if you have to perform 100 index lookups on a table and this table has just about 100 rows – it will cost less to read all rows. The explanation is simple: index lookup (for BTREE indexes) is O(ln N), while reading N rows is O(N). Obviously, O(N) < N * O(ln N).
To prove it – try selecting just 1 row from stories (and by one I mean one row, not sorting the whole table and limiting the result ;), just like:
SELECT `stories`.*
FROM (`stories`)
JOIN `story_keywords` ON `story_keywords`.`story_id` = `stories`.`id`
WHERE `stories`.id = SOMETHING
This query is much more likely to turn to index on story_keywords.
Hope this answers your question :)
Anton is on the right track, but I believe there is more to the problem. As my comment on the OP says, the id columns should most likely be INT types. As the explain shows, the length of the primary key on stories is 767. Usually for an INT type the length would be in the low single digits, but since the column is a VARCHAR, the length is extremely long.
Back to the main problem, since there are no indexes on stories.news_type, stories.order, or story_keywords.story_keywords, the optimizer decided to do a full scan of story_keywords since it will yield the smallest initial result set. If there was an index on one of those columns, it would likely use that first. If you add an index that the query can use it will not need to do a full table scan.
I have a mysql table. When I try to insert, I get this:
Warning: Incorrect string value: '\xAE</...' for column 'value' at row 1
mysql> show create table Configurations;
| Configurations | CREATE TABLE `Configurations` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(255) NOT NULL,
`ckey` varchar(255) NOT NULL,
`value` mediumtext,
PRIMARY KEY (`id`),
KEY `ckey` (`ckey`),
) ENGINE=InnoDB AUTO_INCREMENT=29 DEFAULT CHARSET=utf8 |
mysql> SHOW VARIABLES LIKE 'coll%';
+----------------------+-----------------+
| Variable_name | Value |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
+----------------------+-----------------+
I googled the hell out of the error, and it all seemed to boil down to utf8 being set as my default character set. I've been like that for a while. I'm not sure what else to do. Help?
You could try these-
Check what the encoding of the string is before you enter them into your DB, which probably expects it in utf8.
This guy suggests you update each of your table columns to take in utf8.