This question already has answers here:
Should we always use prepared statements in MySQL and php or when to use these?
(2 answers)
Closed 22 days ago.
I use often simple method in select query and i do not use prepare statement because i think there is no need to use prepare statement in select because in select we view the table . further tell me I think right or we should use prepare statment in select query also?
If yes please Tell me
it is not necessary when there is no user input. It can sometimes still be useful to use a prepared statement when there is input though, even if it's not user input. This is because preparing a statement allows it to be executed more efficiently if it is run lots of times with different data each time
My mother says: the mountain that can be seen is not far away, don't stop trying
Related
This question already has answers here:
Multiple MYSQL queries vs. Multiple php foreach loops
(5 answers)
Closed 6 years ago.
I've always used simple sql update statements inside a loop when updating multiple records. This means the sql is quick but the database is connected to multiple time.
Lately I've been wondering if it would be much better to use a loop to build up a sql statement that does multiple updates in one go.
Does it make much of a difference? I'm using PHP 5.6 & MySql.
Thank you.
The best solution would is to avoid loops altogether.
If you absolutely need to use a loop, you better do it in the database side, as this will eliminate the overhead related to the PHP/database communication.
As documented under Optimizing UPDATE Statements:
Another way to get fast updates is to delay updates and then do many updates in a row later. Performing multiple updates together is much quicker than doing one at a time if you lock the table.
You may also find the page on Optimizing INSERT Statements helpful and informative.
To summarise, in the most general terms: connecting once and sending a single UPDATE statement is better than connecting once and sending multiple UPDATE statements, which in turn is better than connecting multiple times to send a single UPDATE statement on each connection.
Beyond that, there are a host of techniques that can be harnessed to optimise further—but we would need to know the specific configuration and requirements at hand.
I am somewhat new to php and mysql. I have looked at many post about prepared statements and can't seem to find my exact scenario.
Should I use a prepared statement in this scenario?
I am creating a FPDF report of records using a query based on a date range.
While I am displaying each row of data I have another query within the "while" statement that pulls the username data associated with that specific record because the "usernameID" field pulls data via a foreign key in another table. Since this internal query is called more than once before the page finishes loading, should it be a prepared statement?
I know that I can INNER JOIN these tables and have in some scenarios but I am just asking in trying to understand prepared statements better. Is that what it is for, or should they be used for frequently used queries within a session.
I guess what I am getting at is, would the webpage have better performance with the INNER JOIN or should the queries be separated and have prepared statements for the username data that is based on an ID over and over as the page loads?
I have users who keep a session open that when a page is submitted will resend the page for new data, but before that point the connection is closed until they click submit again, so I don't need prepared statements, right?
I welcome any links or better explanations of when or examples to using prepared statements. Sorry if this has been answered already but I appreciate any insight.
Thanks,
T-Boy
exactly its better to use prepared statement but if in case your database is having little data to be handled then a inner join will help you and that will not give much difference in the performance aspect. but if your database is dealing with a tables with huge data inside then its always advisable to use prepared statement.
In prepared statement, the query only will be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize its plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down an application if there is a need to repeat the same query many times with different parameters. By using a prepared statement the application avoids repeating the analyze/compile/optimize cycle. This means that prepared statements use fewer resources and thus run faster.
As per your requirement to generate the reports that will be handled with multiple tables and queries its advisable to use prepared statement but still depends on the data in the table.
This question already has answers here:
How to send a SQL query to database in PHP without waiting for result
(3 answers)
Closed 9 years ago.
Firstly I'm using the deprecated mysql functions (instead of mysqli) knowingly, so please do not tell me I should change to mysqli.
My question is: if I want to do an INSERT or UPDATE and continue processing the PHP script immediately, without waiting for MySQL to complete the task, can I use mysql_unbuffered_query (is that what is does?) or if not, how can I achieve that?
Sorry to break this to you :)
If you use mysqli, with the mysqlnd driver, you can pass a MYSQLI_ASYNC option to the query() method. Unbuffered queries do not help here.
Later on you can use the poll() and reap_async_query() to get to the result.
You can use INSERT...DELAYED for asynchronous insertions (1). I do not believe you can do asynchronous UPDATE's without resorting to spawning another process (2).
(1) but is not available to InnoDB tables
(2) if sticking to the old mysql extension is an absolute requirement
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Are prepared statements cached server-side across multiple page loads with PHP?
I'm working on a new project and using parameterized queries for the first time (PHP with a MySQL DB). I read that they parameterized queries are cached, but I'm wondering how long they are cached for. For example, let's say I have a function 'getAllUsers()' that gets a list of all active user ID's from the user table and for each ID, a User object is created and a call to function 'getUser($user)' is made to set the other properties of the object. The 'getUser()' function has it's own prepared query with a stmt->close() at the end of the function.
If I do it this way, does my parameterized query in 'getUser()' take advantage of caching at all or is the query destroyed from cache after each stmt->close()?
Note: I also use the getUser() function if a page only requires data for a single user object so I wanted to do it this way to ensure that if the user table changes I only ever need to update one query.
Is this the right way of doing something like this or is there a better way?
Update: Interesting, just saw this on php.net's manual for prepared statements (http://php.net/manual/en/mysqli.quickstart.prepared-statements.php)
Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement.
So I guess the main benefit for parameterized queries is to protect against SQL injection and not necessarily to speed things up unless it's a query that will repeated at one time.
Calling mysqli_stmt::close will:
Closes a prepared statement. mysqli_stmt_close() also deallocates the
statement handle.
therefore not being able to use the cached version of the statement for further executions.
I wouldn't mind of freeing resources or closing statements since PHP will do it for you at the end of the script anyway.
Also if you are working with loops (as you described) take a look at mysqli_stmt::reset which will reset the prepared statement to its original state (after the prepare call).
That's good question, from some point of view.
First, about "caching".
There is some special thing about prepared queries - you can send it to server once and then execute it multiple times. It can give some small theoretical benefit for using already parsed and prepared query.
As it seems, you're not using such mechanism, every time preparing every your query. So, there is no caching at all.
Next, about premature optimization.
You've heard of some caching, and it occupied your imagination.
While there is no real need or cause for you to concern about caching or whatever performance issue.
So, there is a rule: do not occupy yourself with performance issues until they are real.
Otherwise you'll waste your time.
This question already has answers here:
PHP: multiple SQL queries in one mysql_query statement
(4 answers)
Closed 8 years ago.
These two PHP MySQL queries work.
mysql_query("DELETE FROM videos WHERE id='10';");
mysql_query("DELETE FROM comments WHERE videoId='10';");
This single query fails due to a MySQL syntax error pertinent to the latter DELETE operation.
mysql_query("DELETE FROM videos WHERE id='10';DELETE FROM comments WHERE videoId='10';");
I've stared hard and can't see the syntax error. What is it?
Not supported by mysql_query see How can I put two queries in one mysql_query? use http://docs.php.net/mysqli.multi-query
You cannot execute multiple queries with mysql_query. If you really want to (security risk!), use mysql_multi_query. (And you should use the newer mysqli_* functions). It's a good idea two embed those two calls in a transaction.
But this looks a lot like you really want to define foreign key constraints. I highly recommend them, if you are already using InnoDB.
Multiples queries are not supported in this function.
http://php.net/manual/en/function.mysql-query.php