Vampiro

Примерно как если вы для каждого блюда будете покупать свою кастрюлю/сковороду.

1. для каждого юзера надо сохранять его id
2. надо заюзать pdo

$dbh = new PDO('mysql:host=localhost;dbname=test', 'root', 'pass',array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));
$sql="update `students` set fio=:fio where id=:id";
$stmt = $dbh->prepare($sql);
try {
	$dbh->beginTransaction();
	$stmt->bindParam(":fio",$_POST['fio']);
	$stmt->bindParam(":id",$_POST['id']);
	//$id = $dbh->lastInsertId(); // для инсертов, тут не надо.
	$dbh->commit();
} catch(\PDOException $e) {
	$dbh->rollback();
}

3. Добавить в код выше цикл по каждой записи из массива $_POST
3.1 посмотреть какие там ключи можно либо отладчиком, либо var_dump($_POST);die();

Как-то так. Остальное вы сами сможете осилить.

php.net/strtotime

google -> mysql left join self

Так вот они, дауншифтеры... добрались и до ИТ. Следующий шаг - сайты без apache/nginx =)

По теме - взрослейте, пожалуйста. В мире куча нерешенных проблем, а эту уже решили использованием баз данных. Возьмите существующую проблемку и решайте, будет интересно!

Не пробовал, но я бы делал так: поле date - хранит день в который кабинет занят, а часы я бы хранил маской (24 бита хватит как раз) тогда выбрав занятые кабинеты в нужный день (это можно сделать по индексу) останется сделать фулскан с битовой операцией.

Для решения задачи, необходимо определиться с терминами.
Пусть "пользователь выбрал производителя" означает выбор из некоего select в форме поиска.
Пусть "пользователь выбрал размер" - это числовое значение в поле формы.
Пусть "отфильтровался товар" - это результат показываемый пользователю после нажатия кнопки "Поиск".
Тогда на стороне сервера в php можно сделать примерно так:

$where[]=1; <- это чтобы фильтровать по всем товарам и не сломать при этом запрос.

if (isset($_GET['madeby']))
{
если мы что-то выбрали в списке производителей...
$where[]="t.madeby='".(int)$_GET['madeby']."'";
}
if (isset($_GET['sizeHi']))
{
если мы что-то указали в размерах - то добавляем еще одно условие, пускай оно в джойн-таблице.
$where[]="parenttable.size<='".(int)$_GET['sizeHi']."'";
}
формируем запрос, собирая все условия в одну строку через "and"
$request = "select * from sometable t left join parenttable on (parenttable.parent_id=t.id) where ". implode(" and ",$where);
и смотрим что получилось.
var_dump($request);
запрос выполняем, результат показываем.

Это не самый оптимальный, но самый простой вариант который должен бы направить вас в "нужную сторону мысли"

я бы делал приблизительно в этом направлении:
select id from table where uid=(select min(uid) from table where uid>N and status=1 ) and status=1

В первой таблице содержится около 3 млн записей, во второй немногим более 350 млн записей

Мне кажется, выгоднее переименовать таблицы, поменяв их местами. Вставлять 3 проще, чем 350. Если же вам необходимо постоянно гонять 350кк записей из таблицы в таблицу — вероятно у вас что-то не так с архитектурой, и следует подумать в сторону триггеров или чего-то кеширующего по дороге от данных к мускулю. Вроде мемкеш сейчас делают простенькую бд, но я тут не владею информацией. надо смотреть по приложению — куда складывать.

Даже не знаю как вам намекнуть, чтобы вы не обиделись. В вашем вопросе нет ничего такого, что не стало бы очевидным, прочти вы хотя бы минимальный объем мануалов по администрированию MySQL. Более того, в тексте, который вы привели содержатся указания на необходимые изменения. Причем, так указаны как переменные, так и рекомендуемые значения. Любой совет тут будет «капитанским», например «посмотрите какие запросы у вас идут мимо индексов (log-slow-queries = /var/log/mysqld-slow-query.log) и проставьте индексы по нужным полям (Adjust your join queries to always utilize indexes).

я бы сделал так:
1. создал новые таблицы.
2. зафигачил туда все из файлов.
3. отключил логи и констраинты
4. insert into новые_таблицы select (все поля кроме PK) from старые таблицы.
5. переименовал таблички, включил констраинты логи.

как-то так, если я правильно осознал условия.

Я не смог найти. Сделал свой за 15 минут, прикрутил бутстрап.мин и смотрится няшно.

ИМХО grant

Я, конечн, жопорукий извращенец, но почему нельзя сделать таблицу subscribers, заполнить ее один раз всеми значениями при добавлении подписчика, а при рассылке тупо из нее дергать?

И еще, в порядке бреда, проблема может быть в пыхе, на этапе выделения оперативки. Попробуйте для теста 5.4 не меняя остального. Не помню на какой версии у меня была такая проблема.

А я бы добавил в таблицу поле "продолжительность", (или вместо "дата завершения") И имел запрос
((время начала + продолжительность)по модулю 24) >= нужная точка

where MOD(`start`+`length`,24)>=16

Я делал выборку квадрата со стороной в 2 радиуса запросом, а более точно для каждой точки считал расстояния в серверной части приложения. Так проще масштабировать и будут индексы задействованы.

В мускуле timestamp хоть и позволяет хранить мс, но не генерит их самостоятельно. Потому никсовый формат с точечкой содержит более точное число. И еще, если с числовыми значениями вся нагрузка на построение запроса отдается клиетской части, то с dateTime возникает соблазн переложить это на БД (dateadd, diff, now, etc), а БД сложнее масштабировать. Получается большая нагрузка на слабое звено. А так да, удобнее с датами крутить.

Выгружаете из старой версии данные, выгружаете из новой структуру. Переименовываете старую для бекапа. Из структуры создаете бд, накатываете в нее данные. Малой кровью у вас вылетит часть данных, структура которых не совпала по каким-то причинам. Эти таблицы (а вы увидите их список по нулевому количеству строк) заполните ручками как «инсерт селект из бекапа» с перечислением конкретных полей.

Это лобовое разовое решение, если вы не заготовили миграционных данных. =/ Еще можно по каждой таблице искать различия и альтеры строчить =)

У вас ложная информация по поводу главной причины, которая не дает Вам использовать нормальный вариант, но не это главное. Делайте таблицы-агрегаты. Посмотрите запросы и постройте индексы. Заполняйте их данными после перевода договоров в стабильные статусы. Если у вас есть лишняя оперативка — лучше отдать ее правильно спроектированной БД, чем скармливать бесполезному в этом случае мемкешу, например.
Договора заканчиваются, периоды закрываются, эти данные становятся статикой и хорошо берутся из агрегатов. Вариант с кешем хорош при частых обращениях к одинаковым данным. Ваши пользователи чаще загружают один и тот же договор, или смотрят последовательно разные? Наверняка последнее, а вы забьете оперативку договорами, которые уже не нужны пользователю. Повторюсь — лучше забить эту оперативку индексами.

Но для общего развития изучить все, об чем выше уже рассказали — мегаполезно.