Оптимизация запросов MySQLi

Есть несколько вопросов..
Есть таблица (онлайнер, т.е. Очень частые выборки, обновление и новые записи. Очищается раз в сутки соответственно записей бывает ~1000-1500).
В связи с чем было бы не лишне как то ускорить работу с этой таблицой.
Вопрос: действительно ли лучше добавлять в запросы типа «SELECT» ограничение «LIMIT 1» хотя заранее известно что результат может быть только 1 или 0?
И есть ли смысл выбирать только id а не * все поля (остальные поля нужны только для вывода информации но не в данном случае)?
Еще вопрос, лучше использовать UPDATE table SET pole=pole+1 или UPDATE table SET pole = '".$var."' и есть ли вообще разница?
3.Ы. Может кто еще что подскажет, как ускорить и какие могут быть 'узкие' места, буду рад так как сам самоучка без учебников.

LIMIT 1 используют для читабельности кода. Тоесть MySQL - серверу это дополнительной нагрузки не создаст.

И есть ли смысл выбирать только id а не * все поля (остальные поля нужны только для вывода информации но не в данном случае)?

Есть. Потому что при выборе всех полей (даже тех, которые не используются) даные помещаются в память процессора php. Так что лучше при выборке перечислять все нужные поля. И для читабельности это плюс.

Еще вопрос, лучше использовать UPDATE table SET pole=pole+1 или UPDATE table SET pole = '".$var."' и есть ли вообще разница?

Пожалуй особой нет. Но мне первый нравится только из-за читабельности. Он более удобен.

На счет лимита, вопрос не в том, где то попалось что типа если нет «лимит 1» то при нахождении совпадения поиск продолжается до конца таблицы, а с ним типа прекращается. Вот не знаю правда это или нет.
На счет всего остального спасибо. +1.

Заранее всегда четко можно знать что запрос вернет одну и только одну запись если в условии запроса поиск проходит по первичному ключу (primary) или уникальному ключу. Тогда в этом случае его использовать не нужно. MySQL серверу и так понятно что запрос вернет либо 0 записей либо 1. А если даже используешь LIMIT 1, то выполение запроса будет возвращать ровно столько записей, которые были указаны в лимите в порядке сортировки, после запрос будет прекращен. Поэтому при создании постраничного вывода используют именно оператор LIMIT

Вот еще такой вопрос, правда что функция
mysqli_multi_query("$q1; $q2"); может принимать только 'селект' запросы, а инсерт, апдейт и т.д. нет?
И чем отличается функция mysqli_real_query() от mysqli_query() а то ни где не могу информацию о ней найти на русском, а по необходимости использую как раз не квери а рил_квери, хотелось бы понять че делаю .

1. Да, все так.
2. Исходя из мануала, это идентичные функции.

Functionally, using this function is identical to calling mysqli_real_query() followed either by mysqli_use_result() or mysqli_store_result().

p.s. А ты библиотеку MySQLi испоьзуешь не в ООП стиле?))) Если так, то к чему такой интерес именно его использовать))) В производительности прироста никакого)

Да опп, просто весь сайт в одном стиле, как то коряво читаться будет когда все на классах а мускул процедурный.
Прироста нет по сравнению с чем?
Меня больше волнует отсутствие замедления а опп предпочитаю по причине возможности хранить данные в одном обьекте и применять к нему кучу разных методов.
Функции отлюбил.
Тогда такой еще вопрос, если я например в мульти квери запущу 10 коунтов, будет разница между этим запросом и скажем 5 отдельными? Тоесть действительно сэкономит время или мало смысла так извращаться?

Так ты используешь, например, так

$mysqli = new mysqli()
$query = $mysqli->real_query($sql);

либо так?

<?
$query = mysql_real_query($sql);
?>

Просто второй вариант, конечно, не ООП, а структурный.
По поводу мульти квери, то нет. Прироста небудет. Это всего лишь клиентская функция, которая посылает запрос и принимает ответ от mysql сервера. По сути дела сами запросы выполняет MySQL - сервер.

Ну тоесть скорость выполнения мульти(1,2,3) будет такая же как и раздельные запросы квери(1), квери(2), квери(3) я так понял?
$sql->query("SELECT* FROM table;");
вот так я использую))
в чем разница между опп и функциями я знаю

Считай да. Возможно даже мультиквери и будет опережать за счет того, что за один сеанс будет передано несколько запросов, но это капля в океане.
Если волнуешься по поводу производительности, то заботься о правильности самих sql-запросов и о проектировании БД.