Hey, I've been investigating SQL_BIG_SELECTS, but the MySQL documentation so far has been pretty unhelpful. I'm looking for some insight as to preventing errors like the one below from appearing.
ERROR 1104: The SELECT would examine too many records and probably take a very long time.
Check your WHERE and use SET OPTION SQL_BIG_SELECTS=1 if the SELECT is ok
At how many rows does MySQL decide that a query is a "BIG SELECT"?
Will proper indexing usually solve this issue?
Is SQL_BIG_SELECTS considered a "last resort", or is it good practice?
How would someone set "SQL_BIG_SELECTS=1" in configuration (without having to execute the query)?
Are there any other alternatives worth knowing?
Thanks in advance!
MySQL determines whether or not a query is a 'big select' based on the value of 'max_join_size'. If the query is likely to have to examine more than this number of rows, it will consider it a 'big select'. Use 'show variables' to view the value of the max join size.
I believe that indexing and particular a good where clause will prevent this problem from occuring.
SQL_BIG_SELECTS is used to prevent users from accidentally executing excessively large queries. It is okay to set it to ON in mysql.cnf or using the command-line option at startup.
You can set SQL_BIG_SELECTS in my.cnf or at server startup. It can also be set on a session basis with SET SESSION SQL_BIG_SELECTS=1.
Not that I can think of. I would just check your query to make sure that you really need to use it. Our servers have it turned on by default, and max_join_size is very large.
You cannot set SQL_BIG_SELECTS in my.cnf or at server startup as it is a session only parameter. I am using MySQL 5.0.60.
As someone has post before, you can not set SQL_BIG_SELECTS on my.cnf at server startup. This kind of variable does not support that.
I had a same problem with a Symfony application showing this annoying error:
The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay
But you can increase the number of varialbe
max_join_size which is related to sql_big_selects
I was able to fix it executing a command as privileged mysql user:
# SET GLOBAL max_join_size=18446744073709551615;
Or you can include it in my.cnf because max_join_size is allowed to set up in configuration file
Well, I hope this can help someone else.
I had more than 2000k records in db, and my query was big-select with exhaustive comparison for duplication removal and updation of certain field...I was told the same by mysql (current version on answer date), and I ended up using index on 2 fields involved in where clause...this should help others too...steps which worked for me were:
Set Index on field
ANALYZE TABLE
run the query
HTH
Following command works for me
SET GLOBAL max_join_size=18446744073709551615;
But what do i need to put in my.cnf file instead of the command?
Btw, i'm using "5.6.12 MySQL Community Server"
SET SESSION SQL_BIG_SELECTS =1;# MySQL returned an empty result set (i.e. zero rows).
SELECT a.`HACtrl` , b.`HBCtrl` , c.`HDCtrl`
FROM `HO110BLote` AS a
LEFT JOIN `HO113BPago` AS b ON ( b.HBHACtrl = a.HACtrl )
LEFT JOIN `HO113BRecibos` AS c ON ( c.HDHBCtrl = b.HBCtrl )
WHERE HAManzana = '03'
AND HALote = '09'
LIMIT 0 , 100
Related
BACKGROUND: I am using PHPMyAdmin tool to run MySQL queries. MySQL version is 5.1.55. I have been using MySQL and this PHPMyAdmin tool for about 7 years and have never seen this error. I am trying to do a simple update query changing ne to gb (column = team, table = info). When I use PHPMyAdmin to try to make the changes,
I get the error message:
UPDATE `pickem`.`info` SET `team` = 'gb' WHERE CONVERT(`info`.`team` USING utf8) = \'ne\'.
QUESTION: What is going wrong here? What is the CONVERT Using UTF8 message coming from. How can I get this to just update the fields I want? I have tried to type the SQL code in myself ex: update info set team ="gb" where team = "ne" , but that does not work either. I get the error message:
There seems to be an error in your SQL query. The MySQL server error output below, if there is any, may also help you in diagnosing the problem
ERROR: Unknown Punctuation String # 22
STR: =\
SQL: update info set team =\"gb\" where team = \"ne\"
It seems the system is putting the slashes in there and it is not letting me do this simple update query.
I appreciate any advice on how to fix this.
Thanks!
You are using phpMyAdmin, right? Try using HeidiSQL.
Also check your PHP version, gpc_magic_quotes is already removed at PHP 5.4.0
I tried running your code on phpMyAdmin, removed the backslashes at \'ne\' and its running fine.
Try running a simple update query in HeidiSQL and check if the problem exists.
UPDATE `pickem`.`info` SET `team` = 'gb'
If it runs fine, modify it like
UPDATE `pickem`.`info` SET `team` = 'gb' WHERE `team` = 'ne'
Additional sidenote - check the encoding and data types. You might have overlooked something...
If your query runs fine on HeidiSQL, you can safely assume that something is wrong with your phpMyAdmin installation/configuration
EDIT:
Are the values you are providing contain '\' inside them? If so, you have to do it like
UPDATE `pickem`.`info` SET `team` = 'gb\\'
EDIT 2:
For the meantime, try to use this to solve your problem temporarily.
UPDATE `pickem`.`info` SET `team` = CONCAT('en') WHERE `team` = CONCAT('gb')
EDIT 3:
If all else fails, you probably should get this or this. Since you are on PHP 5.3, I am afraid to say that the gpc_magic_quotes option might have been enabled by your hosting provider. Contact them.
I'm designing a web interface for my clients database (A .mdb MS Access file). I'm using an ODBC driver to connect to it and the odbc_ functions provided by PHP.
My problem is access's 'append' queries. From what I gather, it's just inserting more rows, but something is breaking the query from executing:
INSERT INTO test ( TITLE, [LEVEL], UNITID, TITLEM, COHORTPLUSOPTIONS )
SELECT \"OPTION ONLY\" AS Expr, Units.LEVEL, UnitOptionNumbers.ID, Units.TITLE,
UnitOptionNumbers.OPTIONCOHORT
FROM UnitOptionNumbers INNER JOIN Units ON UnitOptionNumbers.ID = Units.ID WHERE
(((UnitOptionNumbers.NOAWARD)=Yes));
The most helpful error message I can get is:
[ODBC Microsoft Access Driver] Too few parameters. Expected 1.
Which isn't helpful at all. I'm confident with mySQL, but I just cannot pinpoint the problem here. Please can you help me find the reason the query wont execute, or help me figure out a work around.
Thanks for your time.
I don't have enough reputation to comment but perhaps it could be a problem with the fact that your table "test" has two fields with the same name ("TITLE")
According to Microsoft:
"This error occurs only with Microsoft Access when one of the column names specified in a select statement does not exist in the table being queried."
The solution therefore is to change
SELECT \"OPTION ONLY\" AS Expr
to
SELECT 'OPTION ONLY'
It seems the original code attempted to fill the first field with a default text value I.e "OPTION ONLY". "OPTION ONLY" was being read as a column name it seems.
I'm using a PHP webservice where I have performed a simple SELECT query, and stored it
$result = run_query($get_query);
I now need to perform further querying on the data based on different parameters, which I know is possible via MySQL in the form:
SELECT *
FROM (SELECT *
FROM customers
WHERE CompanyName > 'g')
WHERE ContactName < 'g'
I do know that this performs two Select queries on the table. However, what I would like to know is if I can simply use my previously saved query in the FROM section of the second section, such as this, and if my belief that it helps performance by not querying the entire database again is true:
SELECT *
FROM ($result)
WHERE ContactName < 'g'
You can make a temp table to put the initial results and then use it to select the data and in the second query. This will work faster only if your 1-st query is slow.
PHP and SQL are different languages and very different platforms. They often don't even run in the same computer. Your PHP variables won't interact at all with the MySQL server. You use PHP to create a string that happens to contain SQL code but that's all. In the end, the only thing that counts is the SQL code you sent to the server—how you manage to generate it is irrelevant.
Additionally, you can't really say how MySQL will run a query unless you obtain an explain plan:
EXPLAIN EXTENDED
SELECT *
FROM (SELECT *
FROM customers
WHERE CompanyName > 'g')
WHERE ContactName < 'g'
... but I doubt it'll read the table twice for your query. Memory is much faster than disk.
Thanks for the responses, everyone. Turns out what I was looking for was a "query of query", which isn't supported directly by PHP but I found a function over here which provides the functionality: http://www.tom-muck.com/blog/index.cfm?newsid=37
That was found from this other SO question: Can php query the results from a previous query?
I still need to do comparisons to determine whether it improves speed.
If I understand your question correctly you want to know whether saving the "from" part of your SQL query in a php variable improves the performance of you querying your SQL server, then the answer is NO. Simply because the variable keeping the value is inserted into the query.
Whether performance is gained in PHP, the answer is most probable yes; but depends on the length of the variable value (and how often you repeat using the variable instead of building a new complete query) whether the performance will be notable.
Why not just get this data in a single query like this?
SELECT *
FROM customers
WHERE CompanyName > 'g'
AND ContactName < 'g'
Anyone ran into this one before?
I have a Stored Procedure in SQL with the following Parameters :
exec PaySummary 'DemoTest', 'DemoTest-Mohn-00038', '5/14/12', '5/27/12', 'manager', 'DemoTest-Boyd-00005'
And the following MSSQL Query in PHP running the exact same query.
private function dataTest(){
$strSQL = 'exec PaySummary \'DemoTest\', \'DemoTest-Mohn-00038\', \'5/14/12\', \'5/27/12\', \'manager\', \'DemoTest-Boyd-00005\'';
$a = mssql_query($strSQL);
echo $strSQL;
while($row=mssql_fetch_array($a)){
var_dump($row);
}
}
When run in SQL for this query I will get 3 results...
When run in PHP through SQL I get 2 Results...
Is there any run time settings (Set NoCOUNT on) that you must set on a SQL Stored Procedure to ensure accuracy of the output of results? Or is there a known issue with passing date parameters that would impact the results of a date driven stored procedure?
Microsoft-IIS/5.0 / PHP/5.2.5 / SQL Server 2008 R2 (Where the stored procedure is executed).
For anyone in this same situation... It is caused by the NULL_CONCAT_NULL (or whatever) option in SQL. This one flag can make a stored procedure run a little bit differently depending on how you use concat etc. A good way to solve this problem is via an ISNULL around a lot of your items which seemed to get rid of the issue of getting different results.
Further another option if you do not want to fix your sprocs is to check the path that sql is going through (TCP/IP etc). I noticed when watching the audits that some settings were wildly different depending on the port that sql was running through.
I have a fast running query (sub 1 sec) when I execute the query in SQL Server Mgt Studio, but when I run the exact same query in PHP (on the same db instace)
using FreeTDS v8, mssql_query(), it takes much longer (70+ seconds).
The tables I'm hitting have an index on a date field that I'm using in the Where clause.
Could it be that PHP's mssql functions aren't utilizing the index?
I have also tried putting the query inside a stored procedure, then executing the SP from PHP - the same results in time difference occurs.
I have also tried adding a WITH ( INDEX( .. ) ) clause on the table where that has the date index, but no luck either.
Here's the query:
SELECT
1 History,
h.CUSTNMBR CustNmbr,
CONVERT(VARCHAR(10), h.ORDRDATE, 120 ) OrdDate,
h.SOPNUMBE OrdNmbr,
h.SUBTOTAL OrdTotal,
h.CSTPONBR PONmbr,
h.SHIPMTHD Shipper,
h.VOIDSTTS VoidStatus,
h.BACHNUMB BatchNmbr,
h.MODIFDT ModifDt
FROM SOP30200 h
WITH (INDEX (AK2SOP30200))
WHERE
h.SOPTYPE = 2 AND
h.DOCDATE >= DATEADD(dd, -61, GETDATE()) AND
h.VOIDSTTS = 0 AND
h.MODIFDT = CONVERT(VARCHAR(10), DATEADD(dd, -1*#daysAgo, GETDATE()) , 120 )
;
what settings are on, usually ARITHABORT is the culprit, it is ON in SSMS but you might be connecting with it off
Run this in SSMS while you are running your query and see what the first column is for the session that is connected from PHP
select arithabort,* from sys.dm_exec_sessions
where session_id > 50
Run the SQL Profiler, and set up a trace and see if there are any differences between the two runs.
Using the LOGIN EVENT (and EXISTING CONNECTION) in SQL Profiler with the Text column will show the connection settings of a lot of important SET commands--Arithabort, Isolation Level, Quoted Identifier, and others. Compare and contrast these between the fast and slow connections to see if anything stands out.
SET ARITHABORT ON; in your session, might improve query performance.
https://learn.microsoft.com/en-us/sql/t-sql/statements/set-arithabort-transact-sql?view=sql-server-ver16
Always set ARITHABORT to ON in your logon sessions. Setting ARITHABORT to OFF can negatively impact query optimization, leading to performance issues.