Скорость вашей "поисковой системы" в основном зависит от трех вещей:
- Ваш SQL-запрос
- Ваш проект базы данных
- Конфигурация MySQL
Так что будет нет «переверните этот переключатель, и вы получите супер-пупер». Вам нужно будет заняться всеми этими областями. В дополнение к этому есть много других вещей, которые могут повлиять на производительность. Например: операционная система, жесткий диск, объем памяти и т. Д.
Давайте начнем с конфигурации MySQL. Сначала вы должны попробовать функцию кеширования запросов mysql. Если вы в основном выполняете операции чтения, это может повысить вашу производительность, поскольку все происходит из кеша, и никаких операций ввода-вывода не требуется.
Читайте здесь: MySQL Documentation on Query Cache
Другой важной областью является ваша структура базы данных или какой СУБД вы выбираете. В принципе у вас есть три варианта: InnoDB, MyIsam и Memory (есть другие, но я их действительно не знаю).
Насколько я знаю, MyIsam и Memory поддерживают только блокировку таблицы, а не блокировку строк. Но опять же, если вы в основном выполняете операции чтения, это не повлияет на вас. В общем, они оба быстрее, чем InnoDB. Если бы я был вами, я бы начал с Memory, потому что все в памяти. Но имейте в виду последствия: вам может понадобиться больше памяти, и вы потеряете несохраненные данные, если сервер сработает.
С другой стороны, InnoDB дает вам много безопасности данных и может быть довольно быстрым, если вы правильно настроите его. К несчастью, это широкая область. Поэтому я не буду покрывать все это. Прежде всего, нужно установить innodb_buffer_pool_size примерно в 80% вашей памяти. Поэтому, если у вас 10 ГБ оперативной памяти, вы можете установить его на 8 ГБ.
Если ваш сервер имеет более 8 процессоров, вам также может потребоваться установить innodb_thread_concurrency на большее число. Вы должны использовать 2 * Количество процессоров.
Если вы хотите узнать больше о производительности MySQL, вы должны схватить чашку кофе и читать этот дневник: MySQL performance blog
Еще одна важная вещь могла бы использовать индексы на некоторые из ваших колонок. Но я не могу сказать, будет ли он окупиться в вашем случае, поскольку мои знания о китайском словаре ограничены;)
Вообще говоря, ваше поле первичного ключа должно иметь индекс. В дополнение к этому вы можете использовать индексы для полей, которые вы часто запрашиваете, и которые редко меняются (каждое изменение в поле индекса делает недействительным индекс, поэтому его необходимо перекомпилировать -> проблема с производительностью).
Насколько я знаю, его также следует использовать только в том случае, если в столбце содержится много разных данных. Если у вас есть, например, столбец «пол», который содержит только «мужскую» или «женскую», вы, скорее всего, сломаете только дерево индексов пополам. Если у вас 100 пользователей, вы получите 50 строк. Но если вы будете использовать индекс для своего номера телефона, который в большинстве случаев уникален, вы получите только одну строку, которая намного эффективнее.
Возможно, вам стоит использовать указатель для столбца ch_smpl.
И последнее, но не менее важно ваш запрос. Мой первый совет - выбрать как можно меньше данных. Это означает, что избежать запросов, как это:
select * from ...
В вашем случае: Если вы хотите иметь определение для 我 вы должны использовать этот запрос:
select definition from dictionary where ch_smpl = '我'
и не
select * from dictionary where ch_smpl = '我'
Также избегайте «Like» -Statements с символом процента перед поисковым сервером, так как он дезактивирует индекс для этого столбца.
Например:
select * from dictionary where ch_smpl like '%我'
Вы должны использовать символ процентов только по истечении срока:
select * from dictionary where ch_smpl like '我%'
Один последний кусок советы. Нет специального переключателя, который вы можете перевернуть, как я уже говорил. Есть много вещей, которые вы можете сделать для достижения лучшей производительности. Попробуйте несколько вещей и оцените производительность.