LIKE '％ABC％'クエリによるSQLパフォーマンスの向上
LIKE '％ABC％'クエリを使用してもインデックスは使用されず、これを改善するためにクエリに変更できるものはほとんどないことを知っていますが、実行を速くするために何ができますか？この段階では、フルテキストインデックスを使用するようにクエリを変更することはできません。
いくつかの背景...
システムをAzure VM（注：Azure SQLではなく、Windows 2012で実行されているSQL）で追加の復元力（オフラインバックアップ）のための2番目の場所として立ち上げ、基本的なサーバー仕様を使用してSQLサーバーを「構築」しています。以前のプラットフォームでのLIKEクエリのパフォーマンスは実行に2秒かかりましたが、このAzureプラットフォームでは10秒かかりました。
これは明らかにサーバー仕様の制限ですが、これを改善するにはどうすればよいですか？
クエリの実行中にCPUスパイクを確認できるので、「高速」のAzure CPUが役立つように見えますが、これらの数値も誤解を招く可能性があることを知っています。
だから私の質問は、CPUの改善に集中する必要があるか、それともそれ以上か？
問題のDBはディスク上でわずか300MBであり、照会されるテーブルには約160k行があるため、決して大きくはありません。
ここで間違った木を吠えているのか、それとも他に何をチェックする必要があるのか教えてください。
SQLサーバーは、SQL Server 2014 Stdを搭載したWindows 2012 R2であり、Azure SQLパフォーマンスガイドライン（つまり、専用のストライプドライブ上のデータ）に従って構築されています。
編集
要求通り、これは私がテストしているクエリです：
SELECT Name
FROM Users
WHERE Name like '%ABC%'
それでおしまい。ここでは何も複雑ではなく、小さなデータベースからデータを取得するだけです！
ちなみに、このクエリは実行に10秒かかりますが、 '％ABC％'のような句「AND説明」を追加すると、時間が6秒に短縮されますか？
編集2
わかりました、コメントのフィードバックに続くいくつかの詳細...
私はこのページの情報に従いました： http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
表示されているクエリを実行しました。表示された結果は次のとおりです。 
私には、最初はディスクのように見えましたIOバインドされていますが、平均待機時間は短いようです？私はこの領域の専門家ではないので、アドバイスしてください...
全文検索なしでは、いいえ、SQL Server内で文字列の解析を高速化する魔法は、結果を事前に計算するか、問題でより多くのリソースを投入すること以外にはありません。
何度も繰り返される狭い検索パターンのセットがある場合、それらの基準を満たすテーブルの細い実体化された部分（たとえば、メインテーブルの行を表すPK列のみのテーブル）を維持できる可能性があります。一致'%ABC%'-これらはトリガーを通じて維持できます）。これにより、必要な読み取りの量は減りますが、期間に重大な影響を与えることはありません。
人々が繰り返し不可能な予測不可能な方法で任意の検索文字列を入力している場合、それはとにかく役に立たないかもしれません。
160K行のテーブルでは、10秒は長い時間のようです。 V12を使用している場合（このクエリを相対的に分離して実行できる場合）は、sys.dm_db_wait_statsを使用して、クエリ中に変更された待機を特定できるはずです。300MBのデータを保持できない可能性があります。メモリと待機時間はすべてディスクのチャーンです。この場合、圧倒されたサーバーを共有しているだけかもしれません。そのため、1つの考慮事項は、より良いパフォーマンスを提供するより良い階層に移動することです。
検討できるもう1つのオプションは、アプリケーション側のキャッシュ（memcached、redisなど）です。この場合、アプリケーションのメモリにデータのコピーがあり、SQL Server内ではなく、そこで検索を実行します。