предлагаете телепатическим методом найти ошибку в функциях db_select, которые вы не привели ?
что касается кодировки таблицы, так это кодировка, в которой данные будут храниться. передаваться клиенту они могут и в utf8
скорее всего полей не хватает.
сначала покажите show create table tab1; а потом ждите может кто напишет целиком и запрос или view
расскажите хоть что за программа.
если там можно настроить запрос - напишите прямо в ней запрос.
иначе попробуйте создать так называемое представление - view на основе запроса. для программы это будет выглядеть как таблица.
что-то типа такого оператора:
CREATE VIEW tab_trimmed AS
SELECT pole1,substring(pole2,1,3000),pole4,pole4
FROM tab ;
Возможно потребуется перечислить все остальные поля.
очевидно нужно увеличить у сервера mysql значение max_allowed_packet
Скорее всего это проецируемая память от акселератора типа eaccelerator или xcache.
Вторая цифра - реально используемая память и там всего 12Мб. Так что, я считаю, все нормально.
Чтобы удостовериться, запустите pmap - x <PID> и медитируйте.
вынужден согласиться.
однако не слышал чтобы производительность mysql лечили дефрагментацией. вон в линуксе такие программы как дефрагментаторы просто отсутствуют.
если файловая система предварительно дефрагментированна, выделено свободное место, если массив вы изображаете одной таблицей и все операции идут в основном с ней, то во время работы растет только один файл, а значит фрагментации просто не может быть.
а. мифическая фрагментация данных на одном файле. ага припоминаю
а что вы делали в БД? может просто грамотно переписать?
в SQL с данными можно делать почти все что угодно. а при использовании хранимых процедур и курсоров - вообще все
В данном случае explain со случайными функциями не сможет оценить вероятности , поэтому лучше вызывать сразу после запроса show status like 'handler%'; . Увидите Handler_read_rnd_next равный числу строк.
